Методологии разработки для новичков в контексте BAS
-
Данный ликбез предназначен для того, чтобы начинающие BAS разработчики-непрограммисты не закапывались в своих первых же скриптах, сталкиваясь не только с освоением интерфейса BAS, но и своим перфекционизмом. Также поднимаются некоторые психологические приемы, которые приводят к положительной мотивации разработчика. Безусловно, для опытных разработчиков данный материал может показаться наивным, но он посвящен именно новичкам. Буду рад дополнениям и замечаниям.
Советы по вхождению в BAS.
Советую начинающим разработчикам начинать с написания простых скриптов, но в тоже время нужных им, это важно для психологии, получить пользу с первых шагов, чтобы закрепить в мозгу положительную обратную связь. Также советую сначала как следует изучить используя функцию Лог работу Конструктора Javascript. Так как очень многие вопросы связанные с обработкой получаемых данных можно решать через него быстро, удобно, наглядно. Затем можно изучить работу браузера, выполнение различных действий посредством кликов на страницу. Затем функционал Логики, Списков. Важно помнить, что Конструктор Javascript дублирует некоторый функционал Логики и Регулярных выражений. Для тренировки по созданию сложных циклов можно их создавать в программе flowgorithm.Многопоток и HTTP браузер я рекомендую отложить, так как их освоение потребует вложений времени. Работа в многопотоке позволяет увеличить скорость получения и обработки данных, при этом увеличивая нарузку. HTTP браузер позволяет многократно увеличить скорость работы и снизить нагрузку, но может быть опасен для детектирования ботов и достаточно сложен для освоения новичками.
NPM я советую заниматься в последнюю очередь, так как работа с ним требует разбирательств с документацией модулей, как правило знаний программирования и кроме того, слаба освещена на форуме.
Методологии разработки.
Я описываю базовые методологии, не беря более сложные, такие как agile и scrum, так как для скриптов начального и среднего уровня они не требуются.MVP и TDD
TDD и MVP достаточно близки по логике. Пишем быстро, без перфекционизма, не пытаемся универсализировать скрипт, делаем все для того, чтобы как можно скорее получить рабочий скрипт, пусть и не очень функциональный и с грязным кодом. Затем причесываем, расширяем функционал.Пример. Чтобы заходить в определенный раздел сайта нужно прописать заранее в интерфейсе выбор со всеми вариантами разделов. На первых порах можно обойтись без этого, выбрать определенный раздел и работать только с ним, чем кучу времени тратить на старте. Тут имеет место и психологический момент, человека мотивирует результат, а долгая работа в черновик демотивирует.
Модульное тестирование
Когда не работает та или иная часть кода пишем полностью автономный скрипт, использующий данную часть кода, чтобы вычленить часть кода ответственную за проблему, при этом не гоняя весь скрипт. При этом, например, важно, что мы не обращаем внимание администратора сайта кучей однотипных действий. Меньше тратим времени. И не рискуем напутав случайно в основном скрипте его испортить. Когда разберемся с ошибкой, внедрим полученный код в основной скрипт.Пример. Скрипт заходит на сайт, забирает текст, затем определенное изображение. Не получается забрать изображение. Пишем отдельный скрипт, где надо забирать исключительно изображение, при этом подключаем профиль чтобы не авторизовываться. И начинаем гонять, пробовать. После того, как поняли где ошибка и исправили, внедрим код в основной скрипт и тестируем уже его.
Логирование.
В моей статье Лайфхаки BAS я поднимал вопрос многоуровневого логирования, советую изучить, позволит сократить время на поиск ошибок http://community.bablosoft.com/topic/3521/лайфхаки-basДокументирование.
После того, как скрипт написан, можно разделить код на функции, базовые переменные задать в самой первой функции, также я обычно стараюсь подписать каждый шаг, потому что потом трудно сообразить что и как в скрипте. Документирование нужно чтобы быстро войти в курс дела через некоторое время, а не вспоминать часами что и где ты наворотил.Кроме того, я логику скрипта прорисовываю в сервисе draw.io. Как правило логику прорисовываю уже после создания, так как во время написания многие логические решения приходят на лету. Главная цель прорисовки- такая же как и подписывания каждого шага, быстро вспомнить нюансы скрипта при его доработке или коррекции в случае неработоспособности.
О багах.
Так как в BAS происходит взаимодействие различных элементов и систем, сбои и баги неизбежны, так как система сложная, состоящая из нескольких разнородных подсистем. Лично я рекомендую во время написания скрипта, если Вы понимаете, что столкнулись с багом попытаться его обойти, найти альтернативное решение и уже после того, как закончите этап скрипта или весь скрипт отправлять информацию о баге на форум. Потому что срок решения вопросов с багом может занять несколько недель (над проектом в данный момент трудится один разработчик), это может сильно затянуть разработку Вашего скрипта. Лучше сделать неидеально, с костылями, но получить результат, а когда баг пофиксят переписать, чем ждать неделями исправления имея на руках нерабочий скрипт.
Если у Вас не получается обойти баг, Вы можете с заявкой о баге спросить альтернативный способ реализации и Вам подскажут участники форума.Дневник разработчика.
Ввиду того, что BAS является сложным многофункциональным продуктом если Вы что-то на нем сделали, спустя два-три часа вне процесса разработки надо вникнуть глядя на кубики что сделали, вспоминать суть работы. Поэтому рекомендую вести дневники разработчика, записывая этапы, например:Реализовал сохранение в файл данных о пользователях при помощи Xpath получить каждый текст. Получилось очень удобно, сохраняются сразу все данные.
Таким образом Вы сможете быстро вспомнить что Вы делали и как, это позволит быстрее включиться в работу.
-
Update: добавлен параграф "О багах".
-
Update: добавлен параграф "Дневник разработчика".
