Я устал делать рутинную работу и начал писать для себя программы на Python: что получилось автоматизировать

Я занимаюсь сайтами, SEO, рекламой и всем, что обычно возникает вокруг небольшого digital-бизнеса. Программистом себя никогда особенно не считал. Python появился в моей работе не потому, что однажды я решил идти в разработку, а потому что мне надоело делать руками то, что компьютер явно может сделать вместо меня.

Сначала это были мелкие задачи. Потом Excel-файлы на сотни мегабайт. Потом парсеры, десятки аккаунтов, огромные базы и файл OpenStreetMap по всей территории США. В какой-то момент я поймал себя на том, что на любую скучную рабочую задачу смотрю одинаково: «А мне придется делать это еще раз?» Если ответ «да», есть большая вероятность, что скоро для этого появится скрипт.

Типичная задача веб-мастера. Заказчик присылает изображения в удобном ему формате: WebP, PNG, HEIC, огромные фотографии с телефона. А мне нужны JPG. Когда файлов три, можно открыть редактор, экспортировать каждый и забыть. Когда их несколько десятков, начинаешь подозревать, что занимаешься чем-то не тем.

Так появился один из простейших моих скриптов: берем все изображения в папке и превращаем в JPG. Казалось бы, задача решена. Но через некоторое время выяснилось, что просто JPG недостаточно — для публикации понадобились файлы размером примерно от 600 до 1000 КБ. Значит, программа должна уже не просто сохранить файл, а подобрать качество так, чтобы попасть в нужный диапазон. А потом обнаружился еще один сюрприз: у некоторых WebP был прозрачный фон. При обычной конвертации он становился черным, а вокруг объекта появлялся светлый ореол. Пришлось учить скрипт сначала накладывать изображение на белый фон, а уже потом сохранять.

Примерно так выглядит почти вся автоматизация. Сначала кажется: «Да тут кода на пять минут». Через неделю выясняется, что нужны исключения. Через месяц у тебя уже вполне нормальная маленькая программа, которой ты пользуешься постоянно.

Следующим большим источником раздражения стали таблицы. С маленькими Excel-файлами проблем нет: открыл, поставил фильтр, удалил лишние строки, сохранил. Но однажды файл весит уже около 200 МБ, а задача при этом смешная — удалить строки, где в определенном столбце нет значения. Логика буквально на одну строчку. Но попробуй проделывать такие операции регулярно с большими файлами.

Тогда я начал писать свои инструменты для Excel. Сначала это опять были обычные скрипты: указать путь к файлу, указать столбец, запустить. Потом мне надоело каждый раз открывать код только для того, чтобы поменять название файла. Так появились кнопки, выбор файла, окно с журналом работы и индикатор выполнения. В итоге программа начала выглядеть уже не как код для программиста, а как обычная утилита: выбрал таблицу, нажал кнопку, получил результат.

В какой-то момент я поймал себя на забавной мысли. Я вроде бы не разрабатываю программы, но у меня уже появляются программы, написанные специально для одного пользователя. Для меня.

Есть предел, после которого Excel перестает быть удобным способом работы с данными. У меня появились задачи, где исходные CSV и таблицы весили уже гигабайты, а иногда речь шла о десятках гигабайт. Например, нужно пройти по огромной базе, найти сайты компаний, отбросить ненужные строки, исключить соцсети, привести домены к единому виду и сохранить результат.

Руками здесь уже ничего не сделаешь. Даже если человек способен проверить одну запись за секунду, миллион строк — это больше 11 суток непрерывной работы, без сна и еды. Компьютер относится к подобным перспективам спокойнее. Именно на таких задачах я окончательно понял, что Python для меня — в первую очередь усилитель. Я могу выполнить одну операцию. Компьютер может выполнить ту же операцию миллион раз.

Один из самых показательных моих экспериментов был связан с OpenStreetMap. У меня оказался большой файл с данными по США: `us-260812.osm.pbf`. Задача была не в картах. Мне нужно было пройти по данным и вытащить сайты, которые организации указали в своих объектах: найти нужные поля, извлечь адреса сайтов, очистить их и получить обычный список доменов.

На одном из этапов обработка шла со скоростью примерно 45 000 объектов в секунду. Мне тогда особенно понравился контраст. Ты сидишь за обычным компьютером, на экране быстро бегут цифры, а программа в этот момент перебирает данные по целой стране со скоростью десятки тысяч объектов каждую секунду.

Правда, магия программирования периодически возвращает тебя на землю. В какой-то момент вместо обработки миллионов записей я увидел: `ModuleNotFoundError: No module named 'tldextract'`. То есть программа готова разбирать OpenStreetMap по США, но сначала неплохо бы установить библиотеку.

Еще один интересный этап у меня был с браузерами. Мне понадобилось автоматизировать действия через Selenium, использовать прокси и работать сразу с большим количеством аккаунтов. Когда запускаешь один браузер, все хорошо. Десять — тоже терпимо. А дальше включается простая человеческая логика: если 10 потоков быстрее одного, давайте запустим 20.

На таком количестве потоков компьютер начал периодически перезагружаться. Получилась прекрасная ситуация. Я автоматизировал работу, чтобы экономить время, а потом настолько увлекся экономией, что компьютер решил больше вообще не работать. Пришлось разбираться не только с Python, но и с памятью, охлаждением, нагрузкой и блоком питания. После замены блока питания перезагрузки в итоге исчезли.

Так я узнал еще одно правило автоматизации: ускорять можно до тех пор, пока слабым местом не станет что-нибудь другое. Сначала слабое место — человек, потом интернет, процессор, диск, память. Потом внезапно блок питания.

Поначалу я представлял автоматизацию очень просто: есть задача, пишешь программу, она ее выполняет. Потом начинаешь использовать это в реальной работе и понимаешь: самое интересное начинается не тогда, когда все работает, а когда что-нибудь идет не так.

Недавно я делал небольшую автоматизацию для отправки писем. В базе было 48 компаний. Перед запуском программа создала резервную копию Excel, подключилась к SMTP Яндекс Почты и начала отправку. Первое письмо: `OK — отправлено`. Пауза 131 секунда. Второе письмо: `Connection unexpectedly closed`.

Вот примерно в этот момент понимаешь, зачем программе лог. Если 48 писем отправляешь руками, ты примерно представляешь, на каком находишься. Если это делает код, тебе уже нужно точно знать: что отправлено, что не отправлено, где возникла ошибка, что делать при повторном запуске и не уйдет ли одному человеку одно и то же письмо второй раз.

Чем больше работы отдаешь машине, тем важнее становится контроль за машиной. Это, кстати, сильно изменило мой подход к скриптам. Раньше главное было «пусть работает». Теперь обычно думаю: «А что произойдет, когда оно перестанет работать?»

Я не изучал Python по классическому плану. Не было такого, что сначала я прошел всю теорию, потом решил 200 учебных задач, а затем начал применять язык в работе. Обычно все происходило наоборот: возникала конкретная проблема, я понимал, что не хочу решать ее руками, и начинал искать, как заставить компьютер сделать это вместо меня.

Иногда решение занимало вечер, иногда приходилось несколько раз переделывать, иногда задача оказывалась настолько специфической, что готовой программы для нее просто не существовало. Но в этом и оказался главный плюс. Мне больше не обязательно искать программу, которая делает именно то, что нужно мне. Я могу собрать ее сам. Пусть она будет некрасивой. Пусть ей буду пользоваться только я. Главное, чтобы она выполняла свою работу.

За это время Python поселился практически во всех частях моей работы. Он конвертирует и подготавливает изображения, чистит и объединяет Excel-файлы, перебирает большие массивы данных, вытаскивает домены, проверяет сайты, работает с браузерами, помогает анализировать логи, подготавливает данные для дальнейшей работы, отправляет письма.

И самое смешное, что большинство этих инструментов появилось не из желания что-то запрограммировать. Наоборот. Из желания что-то больше никогда не делать.

При этом я не считаю, что автоматизировать надо вообще все. Если задача возникает один раз и занимает пять минут, я просто делаю ее руками. Потому что можно потратить два часа на написание программы, которая сэкономит тебе пять минут. Это уже не автоматизация, а прокрастинация для людей, которым нравится код.

Для себя я примерно сформулировал простое правило. Если задача повторяется, занимает заметное время, выполняется по понятным правилам и не требует каждый раз какого-то уникального человеческого решения — я начинаю думать о скрипте. Особенно если объем со временем растет. Удалить десять строк проще руками, удалить десять тысяч — уже нет. Обработать одну фотографию проще в редакторе, обработать тысячу — пусть этим занимается компьютер.

Самое важное для меня даже не то, сколько часов получилось сэкономить. Поменялось само отношение к работе. Раньше, получая большую рутинную задачу, я думал: «Сколько времени у меня это займет?» Теперь чаще думаю: «Можно ли сделать так, чтобы это вообще не занимало мое время?»

И это довольно опасная привычка. Потому что после нее становится сложно спокойно смотреть, как кто-нибудь вручную копирует данные из 300 строк одной таблицы в другую. Хочется отобрать у человека мышку и написать ему скрипт.

Сейчас у меня есть простой тест для любой скучной задачи. Мне придется делать это еще раз? Если нет — делаю руками и забываю. Если да — велика вероятность, что в следующий раз это уже будет делать Python.