Чеклист для разработки скриптов

[moonsoon]

Работа с автоматизацией — это не только про написание кода. За каждой строчкой стоит реальный человек, который ждёт от этого кода конкретного результата. За годы выполнения заказов я понял, что техническая сложность — лишь часть задачи. Вторая, не менее важная часть — это ответственность и внимание к деталям, которые превращают рабочий прототип в надёжный инструмент для клиента. И этот опыт вылился в простой, но очень эффективный чек-лист, который я теперь прохожу механически, как пилот перед взлётом, перед тем как отправить любой скрипт.

Когда-то я считал, что главное — это функциональность. Если скрипт делает то, что нужно, значит, работа завершена. Но однажды клиент вернул работу с комментарием: "У меня просто не запускается". Оказалось, что я использовал библиотеку, которая была установлена у меня глобально, но отсутствовала на его компьютере. Это был неловкий момент, и с тех пор я стал более системным. Вот какие шаги я теперь обязательно выполняю:

Проверка переменных окружения. Это мой первый фильтр. Я просматриваю весь код и выношу всё, что может отличаться от одной системы к другой: пути к файлам (например, C:\Users\Имя\Документы), логины, пароли, API-ключи, URL-адреса сайтов. Всё это должно быть либо в конфигурационном файле, либо задаваться через интерфейс BAS. Это позволяет клиенту легко адаптировать скрипт под свою среду, не копаясь в коде и не рискуя что-то сломать.
Тест на "чистую" машину. Теоретически, можно полагаться на описание зависимостей. Практически, лучше увидеть самому. Я использую виртуальную машину с чистой установкой Windows. Устанавливаю только базовый браузер и среду выполнения. Затем пробую запустить свой скрипт. Этот этап помогает поймать все "невидимые" зависимости: те самые .NET Framework, Visual C++ Redistributable, или даже определённые расширения браузера, которые я мог установить год назад и давно забыть о них. Если скрипт работает здесь — он с большой вероятностью заработает и у клиента.
Симуляция сбоев. Мир идеальных условий существует только в мечтах. Интернет обрывается, сайт меняет структуру, капча становится сложнее. Поэтому я намеренно создаю аварийные ситуации: закрываю браузер в самый неподходящий момент, отключаю Wi-Fi, имитирую блокировку со стороны сайта. Цель — не допустить, чтобы скрипт завис или упал с критической ошибкой. Он должен корректно отреагировать: либо попробовать перезапуститься, либо записать подробное сообщение об ошибке в лог-файл, указав, на каком именно шаге произошёл сбой. Это экономит часы на диагностике проблем.
Документирование "что делать, если...". Даже самый надёжный скрипт может вызвать вопросы. Чтобы минимизировать количество обращений после сдачи, я всегда прилагаю к проекту короткий текстовый файл. В нём нет общих инструкций по работе с программой. Только три конкретных пункта: "Что делать, если скрипт не запускается?", "Что делать, если он остановился на шаге X?" и "Куда смотреть, если нужно изменить список сайтов или ключевые слова?". Это не инструкция, а скорее "карта аварийного выхода", которая даёт клиенту чувство контроля и уверенности.
Финальный прогон с записью экрана. Последний аккорд. Я провожу полный запуск скрипта от начала до конца, записывая весь процесс. Позже просматриваю видео. Это позволяет увидеть то, что глаз привыкает игнорировать: слишком долгие паузы, лишние действия мышкой, или, наоборот, слишком быстрые переходы, которые могут вызвать проблемы. Также я проверяю, что финальный результат — файл, база данных или отчёт — создан корректно и содержит ожидаемые данные. Это мой последний шанс поймать что-то, что ускользнуло во время разработки.
Эти пять шагов стали моей личной методологией. Они не требуют огромных затрат времени, но кардинально повышают качество и надёжность моей работы. Это мой главный лайфхак, рождённый из собственных ошибок и отзывов клиентов, которые научили меня, что настоящая ценность — не в сложности решения, а в его безотказной работе.

Впрочем, стоит быть честным: платформа Kwork даёт поток дешёвых заказов, которые помогают начать и получить первые отзывы, но для постоянного и стабильного заработка она вряд ли подходит.

[Roy Mustang]

@moonsoon спасибо за опыт, в целом хороший проект от плохого отличается уровнем продуманности и обработки ошибок и разных проблем, касаемо проксей, это ваще капец, если клаент будет иметь лоу скорости прокси это +500% к работе, потому что нужно обрабатывать казалось бы такое что вообще не нужно, там где то не нажмет, но это еще дефолтная ошибка. А вот если из-за слабого прокси бывает не прорисовывается интерфейс, или он частично прогрузился.

Все нереально медленно с плохими прокси и ты будешь эти ошибки фиксить лярд лет. Поэтому прокси должны быть явно не паблик мусором, это чисто лишняя работа для фрилансера

[Локет]

Базару 0, инфа добрая. Хотя про аварийные ситуации уже не ваша должна быть проблема... Главное чтобы программа после перезапуска работала стабильно, остальное уж не стоит брать во внимание как по мне. Еще тест на чистую машину тоже хз, обычно софты на дедиках запускают, а там каждый хостинг сам выбирает что блочить и как работать, так что..