Самые значительные изменения в моем подходе к написанию кода произошли не благодаря изучению нового синтаксиса. Они произошли в те моменты, когда то, что я считала «достаточно хорошим», внезапно приводило к сбою под нагрузкой.
Никаких драматических провалов. Никаких аварийных ситуаций в продакшен-среде. Никаких сообщений в Slack, написанных капслоком.
Просто постепенное накопление проблем. Скрипты, которые однажды сработали, но потом их стало невозможно использовать повторно. Проекты, которые казались завершенными, пока мне не пришлось к ним вернуться. Автоматизация, которая сегодня сэкономила мне десять минут, а на следующей неделе обошлась в три часа.
Вот что стало настоящим поворотом в моем мышлении.
После четырех лет почти ежедневного создания Python-кода я перестала думать, что программирование — в основном написание логики. Это не так. Качественное программирование — в основном принятие решений, которые выдерживают столкновение с реальностью.
Это представление изменило все.
Вот пять изменений, которые перепрошили мое мышление о программировании, особенно об автоматизации (ни одно из них не выглядит эффектным, но все вместе они способствовали моему профессиональному росту).
1. Я перестала писать код, чтобы завершить задачу, и начала писать код, чтобы устранить ее
Долгое время я писала код как машинистка, быстро справляющаяся с бумажной работой.
Нужно переименовать файлы? Пишу скрипт. Нужно очистить CSV? Снова пишу скрипт. Нужно собрать данные? Опять скрипт.
Технически это работало. Скрипт запускался. Задача выполнялась. Галочка поставлена.
Но мышление мое оставалось примитивным.
Профессионал никогда не задается вопросом: «Как автоматизировать задачу?».
Он ставит вопрос так: «Почему эта задача все еще существует?».
Этот вопрос меняет подход к разработке.
Этот вопрос меняет то, как вы строите системы.
Вместо того чтобы автоматизировать один повторяющийся шаг, я начала прослеживать весь рабочий процесс. Большая часть повторяющейся работы не сводилась к одной задаче. Это была цепочка мелких привычно выполняемых ручных решений.
Вот где необходима автоматизация.
Генератор отчетов — просто полезно. Система, которая собирает данные, проверяет их, форматирует, отправляет и логирует ошибки — настоящий рычаг.
Вот в чем был сдвиг. Я перестала писать скрипты и начала устранять целые рабочие процессы.
def automate_report(data):
cleaned = validate(data)
report = build_report(cleaned)
send(report)
log_status(report)Выглядит просто. В этом и суть.
По-настоящему полезная автоматизация — не та, что выглядит умной. Это та, которую не замечаешь.
Совет профессионала: Эффективная автоматизация экономит время не один раз. Она навсегда избавляет от необходимости принимать решения.
2. Я перестала доверять «работающему коду»
В эту ловушку попадает каждый начинающий разработчик.
Вы запускаете скрипт. Он работает. Вы чувствуете себя умным. Идете дальше.
Затем открываете его через три недели и понимаете, что все держится на допущениях и оптимизме.
Это был один из самых дорогих уроков, которые я усвоила на старте карьеры.
Работающий код — не самоцель. Надежный код — вот цель.
Между ними есть разница.
Скрипт, который работает на вашей машине с вашими файлами и вашими данными, нельзя считать завершенным. Ему просто повезло.
Я стала рассматривать ситуацию «он запускается» как начало, а не финишнную черту.
Это означает, что я стала задавать правильные вопросы:
Что произойдет, если файл отсутствует? Что произойдет, если API вернет мусор? Что произойдет, если это запустится 500 раз вместо 5?
Автоматизация терпит неудачу по ряду банальных причин. Отсутствующие ключи. Неверные данные. Незаметно накапливающиеся проблемы с форматированием. Лимиты запросов. Дублирующиеся строки. Это не обрушающие систему баги, но именно они приводят к ее постепенному разрушению.
Поэтому я перестала писать код, который должен пройти по «счастливым путям», и начала писать код, рассчитанный на реальные условия.
if not file_exists(path):
raise FileNotFoundError(f"Missing input: {path}")Маленькие защитные барьеры изменили все.
Лучшие разработчики на Python — не те, кто пишет самый виртуозный код. Это те, чей код продолжает работать, когда вокруг царит хаос.
3. Я начала оптимизировать для повторного использования, а не для завершения
На это у меня ушло больше времени, чем следовало бы.
Раньше я заканчивала проекты так, будто пыталась от них сбежать.
Сделать. Выпустить. Закрыть вкладку. Никогда не оглядываться назад.
Такой подход кажется продуктивным, пока не осознаешь, что в шестой раз решаешь одну и ту же проблему, лишь с немного другими именами переменных.
В какой-то момент я заметила, что снова и снова переписываю одни и те же утилиты:
- загрузчики файлов;
- обработчики повторных попыток;
- обертки API;
- функции очистки;
- помощники экспорта.
Разные проекты. Один и тот же скелет.
Именно тогда я перестала рассматривать код как конечный результат и начала воспринимать его как инфраструктуру.
Теперь, создавая что-то полезное, я задаю себе один вопрос, прежде чем двигаться дальше:
«Понадобится ли мне это снова?»
Если да, то созданное становится инструментом, который можно использовать повторно.
Один этот навык изменил скорость, с которой я создаю код. Большая часть той экономии времени, которую называют «опытом» разработчика, — результат меньшего количества переизобретений.
4. Я перестала рассматривать ИИ как функцию и начала относиться к нему как к инфраструктуре
Многие разработчики используют ИИ как некий трюк.
«Подытожь это». «Перепиши то». «Сгенерируй текст». Готово.
Полезно, но поверхностно.
Настоящая сила ИИ проявилась, когда я перестала воспринимать его как функцию и начала относиться к нему как к компоненту системы.
Это изменило мой подход к созданию автоматизации.
Вместо вопроса: «Где здесь можно применить ИИ?»
Я начала задаваться вопросом: «Где человеческое решение замедляет этот рабочий процесс?»
Именно там и нужно применять ИИ.
Не везде. Не слепо. В узких местах принятия решений.
Классификация. Резюмирование. Тегирование. Извлечение. Ранжирование. Валидация. Преобразование беспорядочных входных данных в структурированные действия.
Вот где ИИ перестает быть впечатляющим и начинает быть полезным.
Одна из самых практичных систем, которые я создала, была совсем не эффектной. Она принимала беспорядочные входные данные от клиентов, очищала их, классифицировала намерения, направляла в правильный рабочий процесс и автоматически генерировала структурированные результаты.
Никаких скриншотов дэшбордов. Никакой демонстрации «посмотрите, на что способен ИИ».
Просто меньше ручной работы. Меньше узких мест. Лучшая пропускная способность.
Вот как выглядит продуманная автоматизация.
ИИ — это не магия. Это просто очень быстрый уровень для обработки неоднозначности.
Поняв это, я перестала создавать демонстрации ИИ и начала создавать системы, которые люди реально используют.
5. Я начала мыслить системами, а не скриптами
Это был самый большой сдвиг в моем сознании.
Большинство кода новичков изолировано. Входные данные поступили. Выходные данные получены. Готово.
Для обучения этого вполне достаточно. Но не для масштабирования.
Настоящая автоматизация — это не один скрипт. Это система, у которой есть:
- входные данные;
- валидация;
- состояния ошибок;
- повторные попытки;
- выходные данные;
- логи;
- мониторинг;
- поддержка.
Это звучит менее захватывающе, чем написание умного скрипта. Но в этом и разница между чем-то впечатляющим и чем-то полезным.
Когда я начала мыслить системами, мой код стал менее уязвимым.
Я перестала спрашивать: «Как мне это написать?»
И начала задаваться вопросом: «Как это выдержит реальные испытания?»
Один этот вопрос быстро улучшает архитектуру.
Потому что показывает: вы думаете о граничных случаях до того, как они случаются. О наблюдаемости до отказа. Об обслуживании до развертывания.
Вот так скучный код становится ценным кодом.
А «скучная» автоматизация — это просто комплимент.
Системы, которые приносят больше всего денег, обычно наименее драматичны. Они работают тихо. Отказывают предсказуемо. Восстанавливаются без проблем. Избавляют от работы, которую никто не хочет делать дважды.
Вот в чем суть.
Заключение
Самые значительные изменения в программировании редко бывают техническими. Чаще они ментальные.
Вы совершенствуетесь не потому, что выучили очередной фреймворк. А потому, что перестаете думать как человек, пишущий код, и начинаете думать как человек, создающий механизмы для оптимизации.
Вот это настоящий сдвиг.
Python помог мне понять это быстрее, чем что-либо другое, потому что он устраняет достаточное количество препятствий, чтобы показать, насколько продуктивно вы мыслите. И в конечном итоге это становится самой сутью дела.
Как только вы перестаете писать скрипты для выполнения задач и начинаете создавать системы для их устранения, программирование становится другим.
Чище. Четче. Честнее.
И гораздо мощнее.
Читайте также:
- Куча советов по программированию, которые я дал бы себе сам после 15 лет опыта
- Вы толковый программист, если сможете решить эту задачу
- Практики быстрого программирования
Читайте нас в Telegram, VK и Дзен
Перевод статьи Maria Ali: 5 Programming Shifts That Changed How I Think
