Примечание: всё, что говорится в этой статье, можно отнести и к любому другому языку с динамической типизацией (скажем, Ruby). Я делюсь своим опытом и мытарствами конкретно по Python только потому, что сам пользуюсь этим языком.
Изначально я осваивал программирование на Python, и этот язык до сих пор занимает особое место в моем сердце. Именно он научил меня, как нужно подходить к программированию, как моделировать проблему, которую должен решить код, и общаться с компьютером. Свою текущую работу (как и предшествующую) я получил благодаря знанию Python. Я был его фанатом и евангелистом, проводил много времени в сообществах по Python – помогал другим и учился сам. Когда я стал выступать в роли наставника для новичков, то из языков выбрал для себя Python.
Хорошо помню, как у нас с другом состоялся такой разговор.
Как же я ошибался. На тот момент я доводил код до продакшна на Python, но пользователей у нас было немного. Опыта работы с другими языками у меня не имелось вообще.
Когда я пришел в стартап, где работаю сейчас (команда состояла из трех разработчиков), то начал изучать Go. Я отвечал за разработку нескольких сервисов. Для части из них я выбрал Python, потому что был с ним лучше всего знаком и мог быстро выдавать результат. Для отдельных задач больше подходил Django. С ними мне удавалось быстро доводить код до релиза, и так я создал ряд сервисов, которые до сих пор в ходу.
Спустя пару месяцев я перестал писать новый код на Python. Для новых сервисов, в том числе и ключевых, составляющих ядро функциональности, стал использоваться Go, и я подключился к работе над ними. С тех пор прошли годы. Я продолжал между делом осваивать Python; например, когда вышла async, я переписал один из своих побочных проектов, чтобы внедрить новые возможности.
Несколько месяцев назад мы обновили некоторые внутренние API и библиотеки, и в несколько сервисов, написанных на Python, понадобилось внести изменения. Сначала я был рад шансу снова поработать с этим языком, но энтузиазм быстро угас.
Первая проблема, вставшая передо мной, была связана с пониманием кода. Немало времени потребовалось, чтобы разобраться, какие есть виды объектов, что получают функции и что делают с тем, что получают. В коде действительно обанружилось некоторое количество юнит-тестов, но покрытие было так себе. Приходилось гадать и проводить многочисленные тесты после любых изменений.
Для нескольких модулей мне не удалось найти подсказок в среде разработки. У меня вошло в привычку держать исходный код открытым в соседней вкладке и постоянно сверяться по мере того, как пишу новый код. Без типов (и подсказок типов) было сложно понять, как использовать функцию. С точки зрения рефакторинга наличие в языке типов многое меняет: один взгляд на аннотацию типа – и я уже знаю, что делать.
После всех этих игр в угадайку и переписывания, как мне убедиться, что все изменения будут работать эффективно? Единственный способ обрести уверенность – запускать код и проверять, чтобы каждая строка выполнялась при всех возможных комбинациях.
Годы разработки на Go выработали во мне приятное убеждение: компилируется – значит работает (а с Rust еще того хлеще: компилируется – значит не возникнет проблем с памятью и состояния гонки). Компиляция оперативно дает обратную связь, что сильно облегчает внесение изменений.
Подсказки типов до некоторой степени решают проблему, но баги всё равно проскакивают. Оптимальный путь – юнит-тестирование. Однако это не всегда возможно, например, бывает, что в команде сложно установить единые правила или же вам передают legacy-проект. Но работает ли на практике введение строгих правил? Можно выстроить такой пайплайн CI/CD, что покрытие достигнет 100%, но от этого будет страдать производительность команды и, вне всякого сомнения, нервы сотрудников.
Мне нужна система, которая сводит риск допустить ошибку к минимуму, и при помощи юнит-тестирования и пайплайнов CI/CD я могу ее получить. Но типобезопасность обеспечивает то же самое просто по умолчанию.
Я сделал для себя вывод: реальная жизнь далека от идеала. Кодовые базы без комментариев, документов, юнит-тестов – обычное дело. С этим неизбежно сталкиваешься, если работаешь в команде с крупной кодовой базой. И при таком раскладе работа на Python превращается в чистое мучение.
Когда я имел дело с языками со строгой типизацией, то думал: ну вот, придется теперь определять везде типы, заранее создавать структуры (или классы) и иногда сочинять всё это из головы, потому что информации еще нет или окончательное решение не принято. И все эти жалобы вполне справедливы. Прототипирование на Rust займет у меня много времени. Python же даст возможность быстро дойти до релиза… но только один раз.
Рефакторинг сводится к тому, что мы читаем существующий код, вникаем в него и вносим изменения. Типы – это что-то вроде бесплатной документации. На мой взгляд, без них трудно понимать и осмыслять код. Типы позволяют мне быстро и с уверенностью вносить небольшие изменения, получая гарантию их корректности в виде успешной компиляции.
Проводить рефакторинг на Python мне тяжело. Не могу даже пожаловаться на того, кто его написал – это ведь был я сам, всего несколько лет назад! Можно было сгладить эти проблемы при помощи юнит-тестов и подсказок типов. Но удалось бы мне сохранить высокую скорость работы, если бы я тратил на всё это столько времени?
Со статическими языками ты расплачиваешься единожды, в самом начале (есть в этой схеме что-то общее с разработкой через тестирование), но позже будешь себе благодарен за то, что это сделал. Если я возвращаюсь к проекту спустя годы, то предпочел бы, чтоб он был написан на языке со строгой типизацией. На Python я написал много интересных вещей (вот, например, пара из них) и намерен продолжать изучать его и использовать в побочных проектах. Но крупные кодовые базы на Python отныне будут вызывать у меня ужас.
Изначально я осваивал программирование на Python, и этот язык до сих пор занимает особое место в моем сердце. Именно он научил меня, как нужно подходить к программированию, как моделировать проблему, которую должен решить код, и общаться с компьютером. Свою текущую работу (как и предшествующую) я получил благодаря знанию Python. Я был его фанатом и евангелистом, проводил много времени в сообществах по Python – помогал другим и учился сам. Когда я стал выступать в роли наставника для новичков, то из языков выбрал для себя Python.
Хорошо помню, как у нас с другом состоялся такой разговор.
Друг: C# сильно упрощает жизнь за счет типов.
Я: Как-то не ощущал потребности. А какая от них польза?
Друг: А как ты управляешься с функциями, которые могут принимать любой тип аргумента?
Я: На то у меня юнит-тесты плюс высокая степень покрытия кода. Достаточно небольшого изменения, чтобы охватить остальные. К тому же к функциям прилагается документация, там сказано, для чего они нужны и какие аргументы принимают. Плёвое дело.
Как же я ошибался. На тот момент я доводил код до продакшна на Python, но пользователей у нас было немного. Опыта работы с другими языками у меня не имелось вообще.
Когда я пришел в стартап, где работаю сейчас (команда состояла из трех разработчиков), то начал изучать Go. Я отвечал за разработку нескольких сервисов. Для части из них я выбрал Python, потому что был с ним лучше всего знаком и мог быстро выдавать результат. Для отдельных задач больше подходил Django. С ними мне удавалось быстро доводить код до релиза, и так я создал ряд сервисов, которые до сих пор в ходу.
Спустя пару месяцев я перестал писать новый код на Python. Для новых сервисов, в том числе и ключевых, составляющих ядро функциональности, стал использоваться Go, и я подключился к работе над ними. С тех пор прошли годы. Я продолжал между делом осваивать Python; например, когда вышла async, я переписал один из своих побочных проектов, чтобы внедрить новые возможности.
Несколько месяцев назад мы обновили некоторые внутренние API и библиотеки, и в несколько сервисов, написанных на Python, понадобилось внести изменения. Сначала я был рад шансу снова поработать с этим языком, но энтузиазм быстро угас.
Разработка на кофейной гуще
Первая проблема, вставшая передо мной, была связана с пониманием кода. Немало времени потребовалось, чтобы разобраться, какие есть виды объектов, что получают функции и что делают с тем, что получают. В коде действительно обанружилось некоторое количество юнит-тестов, но покрытие было так себе. Приходилось гадать и проводить многочисленные тесты после любых изменений.
Для нескольких модулей мне не удалось найти подсказок в среде разработки. У меня вошло в привычку держать исходный код открытым в соседней вкладке и постоянно сверяться по мере того, как пишу новый код. Без типов (и подсказок типов) было сложно понять, как использовать функцию. С точки зрения рефакторинга наличие в языке типов многое меняет: один взгляд на аннотацию типа – и я уже знаю, что делать.
После всех этих игр в угадайку и переписывания, как мне убедиться, что все изменения будут работать эффективно? Единственный способ обрести уверенность – запускать код и проверять, чтобы каждая строка выполнялась при всех возможных комбинациях.
Годы разработки на Go выработали во мне приятное убеждение: компилируется – значит работает (а с Rust еще того хлеще: компилируется – значит не возникнет проблем с памятью и состояния гонки). Компиляция оперативно дает обратную связь, что сильно облегчает внесение изменений.
Юнит-тесты и подсказки типов
Подсказки типов до некоторой степени решают проблему, но баги всё равно проскакивают. Оптимальный путь – юнит-тестирование. Однако это не всегда возможно, например, бывает, что в команде сложно установить единые правила или же вам передают legacy-проект. Но работает ли на практике введение строгих правил? Можно выстроить такой пайплайн CI/CD, что покрытие достигнет 100%, но от этого будет страдать производительность команды и, вне всякого сомнения, нервы сотрудников.
Мне нужна система, которая сводит риск допустить ошибку к минимуму, и при помощи юнит-тестирования и пайплайнов CI/CD я могу ее получить. Но типобезопасность обеспечивает то же самое просто по умолчанию.
Я сделал для себя вывод: реальная жизнь далека от идеала. Кодовые базы без комментариев, документов, юнит-тестов – обычное дело. С этим неизбежно сталкиваешься, если работаешь в команде с крупной кодовой базой. И при таком раскладе работа на Python превращается в чистое мучение.
Дает ли Python преимущество в скорости?
Когда я имел дело с языками со строгой типизацией, то думал: ну вот, придется теперь определять везде типы, заранее создавать структуры (или классы) и иногда сочинять всё это из головы, потому что информации еще нет или окончательное решение не принято. И все эти жалобы вполне справедливы. Прототипирование на Rust займет у меня много времени. Python же даст возможность быстро дойти до релиза… но только один раз.
Рефакторинг сводится к тому, что мы читаем существующий код, вникаем в него и вносим изменения. Типы – это что-то вроде бесплатной документации. На мой взгляд, без них трудно понимать и осмыслять код. Типы позволяют мне быстро и с уверенностью вносить небольшие изменения, получая гарантию их корректности в виде успешной компиляции.
Проводить рефакторинг на Python мне тяжело. Не могу даже пожаловаться на того, кто его написал – это ведь был я сам, всего несколько лет назад! Можно было сгладить эти проблемы при помощи юнит-тестов и подсказок типов. Но удалось бы мне сохранить высокую скорость работы, если бы я тратил на всё это столько времени?
Со статическими языками ты расплачиваешься единожды, в самом начале (есть в этой схеме что-то общее с разработкой через тестирование), но позже будешь себе благодарен за то, что это сделал. Если я возвращаюсь к проекту спустя годы, то предпочел бы, чтоб он был написан на языке со строгой типизацией. На Python я написал много интересных вещей (вот, например, пара из них) и намерен продолжать изучать его и использовать в побочных проектах. Но крупные кодовые базы на Python отныне будут вызывать у меня ужас.
