Работа с фреймворками Python: преимущества и проблемы

Фреймворки помогают ускорить разработку и сделать её приятнее. Программу, которая раньше писалась неделю и занимала 1000 строк, с помощью фреймворка вы можете создать за пару часов и уместить в 50 строчках кода. Некоторые решения даже поставляются в виде подписки на сервисы, и программисту остаётся только написать шаблонный код — остальное сервис сделает сам. Несмотря на всё это, в российском IT всё равно чаще выбирают писать что-то своё, тратя на это много сил, времени и денег. Почему так происходит, попытались разобраться с Денисом Наумовым, Techlead и Data Engineer в Skyeng. 

Какая парадигма сложилась в российском IT

Большая беда российского IT — всегда писать что-нибудь своё. Мы берёмся за написание, тратим на это полтора года, расходуем выделенный бюджет, ещё несколько месяцев убеждаем заказчика утвердить новый бюджет и так по кругу. Для сравнения в зарубежных компаниях либо покупают уже готовый продукт, либо собирают его из готовых компонентов, которые дружат между собой. Писать с нуля там не принято. 

Почему в России по-другому? У меня есть гипотеза, что все идут за прикольными техническими решениями, а интегрировать — муторное и невесёлое занятие. Но бизнес не про интересные задачи и рокет-саенс разработку. Он про то, чтобы дать пользователям быстро и качественно работающий продукт.

Вместо того чтобы долго изобретать что-то самостоятельно, ты можешь зайти на GitHub и поискать, сталкивался ли кто-то ещё с похожей проблемой. А с ней наверняка уже кто-то сталкивался, поэтому можно взять готовое решение и использовать его.  Даже если такое решение не найдётся, взять чью-то кодовую базу и адаптировать её под себя всё равно проще. К сожалению, open source в России не очень развит, и большинство выбирает писать что-то своё.

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

Я начинал в аутсорсинговой компании, которая работала на США. Там трудилось около 8 тысяч сотрудников, и никто особо не пытался ускорить разработку. Цели, бюджеты и сроки оговаривались заранее, поэтому делать что-то «сверх» было незачем. Мой подход к работе изменился после того, как я попал в стартап. Там я ощутил, что мои решения напрямую влияют на бизнесовые показатели, и что неплохо было бы не только закрывать задачи быстрее, а ещё и дополнять планы по разработке своими идеями. 

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

История, как фреймворки и библиотеки Python помогают бизнесу

Пару лет назад я работал в компании, которая создавала прикладное программное обеспечение для управления дата-центрами. Первое время мы писали ПО на C++, и, поскольку это низкоуровневый язык, было сложно выполнять даже базовые задачи. Например, чтобы заставить программу принять запрос пользователя через API и смэтчить на него какое-то действие, приходилось углубляться в технические детали. Требования к специалистам были сильно перекошены в сторону знания операционных систем и сетевого оборудования, хотя утрированно задача стояла сделать так, чтобы сервер выключался, когда пользователь нажимал кнопку «Выключить». 

Мы решили перейти на Python, где были не только готовые фреймворки для создания Web API, но и сделанные другими людьми (часто вендорами оборудования) библиотеки. Эти библиотеки позволяли передачей одной строчки в нужный метод сказать, что сервер должен быть выключен, и он выключался. При этом происходили все необходимые проверки — их не нужно было писать вручную и контролировать, выключился ли сервер правильно. После этого работа пошла быстрее: то, что раньше мы делали неделю, теперь удавалось закончить за полтора часа.

Python — популярный язык с низким порогом входа, но это не значит, что он чем-то хуже других. Сама идея языка заключается в том, чтобы делать просто то, что в большинстве других языков делается сложно. Есть и другая сторона медали: чем ближе задача к «железу», тем этой простоты становится меньше, а обобщённые конструкцию начинают мешать. И требуется уже не просто уметь программировать, а иметь представления об алгоритмах и особенностях работы с ОС, в идеале ещё и знать C. Поэтому люди, решающие задачи на Python, стараются предоставлять библиотеки. Эти библиотеки уже отлажены и готовы к работе — бери и используй. И это всё ещё лучше, чем писать своё решение, потому что:

• своё решение ты пишешь дольше;

• своё решение ты пишешь без поддержки других программистов из сообщества;

• своё решение ты пишешь с непредсказуемым результатом. 

Кейсы бывают разные, но обычно проще идти по пути, который до тебя прошла тысяча других человек, чем самостоятельно набивать шишки. 

Ещё одна история, как фреймворки и библиотеки Python помогают бизнесу

В своё время я узнал о Слёрме благодаря статье, которую перевёл и выложил Игорь Олемской. В ней рассказывалось про Python-фреймворк, который и сегодня уделывает 90% других фреймворков на Python по производительности. И даже Go-шный fasthttp из коробки уделывает. 

Тогда были распространены фреймворки, которые предлагали примерно стандартную питоновскую производительность — в лучшем случае переваривали 30-40 тысяч лёгких запросов в секунду. Для моей задачи требовалось переваривать 500 тысяч запросов в секунду. Поначалу мы просто заливали проблему железом, но нужно было другое решение. В какой-то момент мы отчаялись найти простой вариант и думали переписать всё на C++, но тут на глаза попалась статья Игоря. В ней рассказывалось о фреймворке japronto, у которого были удобные питоновские абстракции и интеграция с производительным веб-сервером, написанным на C. Этот фреймворк мог перемалывать какие-то чудовищные объёмы запросов в секунду, при этом о нём почти никто не знал — он находился в альфа-версии. 

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

Почему же фреймворки не любят

Фреймворки скрывают много работы внутри себя. Если нужно решить не совсем стандартную задачу, придётся погружаться в реальное программирование на языке, а не на тех абстракциях, что предоставляет фреймворк. Поэтому крайне ценятся специалисты, которые не только хорошо знают фреймворк, но и при необходимости могут расширить его так, чтобы он соответствовал всем требованиям, которые бизнес ставит перед разработкой. Для этого важно знать о подводных камнях, которые могут возникать в работе. Самые распространённые связаны с документированием, работой с данными и поддержкой системы. 

Документирование того, что ты делаешь

Фреймворк позволяет не только быстро писать код, но и документировать этим кодом систему. Когда ты описываешь поведение, из этого же поведения генерируется документация, по которой можно быстро понять, что происходит, заонбордить человека и др. Об этом мало кто знает, а те, кто знают, не хотят использовать. Причина — непонимание всей широты функциональности, которую предоставляют фреймворки. 

Работа с данными

Структура данных бывает сложной. Скажем, набор табличек, некоторые из которых связаны сами с собой. Такое часто случается, когда люди пишут коренную функциональность. Сущность вроде одна, а вариантов использования множество. При хороших обстоятельствах мы имеем набор нормализованных табличек, из которых на лету строится сущность под определённый вариант использования, но чаще всего — широкую таблицу со связью «сам в себя». И то, и другое вызывает проблемы, когда нужно организовать хранение данных и их обработку на стороне программы. 

Развитие и поддержка системы

Функциональность часто дополняется, так как возникают новые запросы от пользователей. Но, внося новые изменения, ты не знаешь, как они повлияют на старые. Классическая проблема — в одном месте починил, в другом поломалось. 

И решить её помогают фреймворки. Они позволяют быстро настроить тестирование всех регрессионных зависимостей, которые тянутся из прошлого. Благодаря этому, когда ты добавляешь новую фичу, ты уверен в том, что все будет работать. 

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

Фреймворки на Highload-проектах

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

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