Мы поговорили с техлидом и дата-инженером Skyeng, автором курса Python для инженеров Денисом Наумовым.

У Дениса за плечами — более 5 лет в разработке и анализе данных на Пайтоне. Выстраивает системы реагирования на триггерные события во взаимодействии пользователя с продуктами, а в качестве DataOps развивает аналитические инфраструктуры и управляет потоками данных.

Краткий экскурс в историю

Устроившись на первую работу в 2014 году, Денис сразу стал писать на C и C++. Компания разрабатывала веб-сервисы и приложения, как все. Была своя специфика, но ничего сверхъестественного. 

Работать с C++ было не слишком удобно, потому что он имеет достаточно высокий порог вхождения. Этот язык не самый лаконичный, писать на нем надо дольше. Плюс, можно запросто ошибиться, а рассчитывать на то, что он поправит своим синтаксисом и инструментами, не приходится. Следовательно, на тестирование и отладку уходит больше времени и ресурсов. Все это увеличивает Time to Market.

Компании постоянно нужен был человек с низкоуровневым стеком, который будет согласен (и способен) писать веб-приложения. Найти такого было затруднительно, поэтому начали рассматривать альтернативы, что привело к Пайтону — самому удачному варианту на рынке на тот момент. Сейчас по удобству и производительности большую конкуренцию Пайтону составляет Go, но тогда его еще не было.

Что такого хорошего в Python

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

2. Очень богатая экосистема. В C++ есть ряд базовых библиотек, которые умеют супербыстро работать с примитивами, но чтобы создать нечто большее, надо самому придумывать кучу абстракций. Если нужно создать веб-фреймворк, то начинать придется с голого веб-сервера. Из абстракций есть только обращения через сокеты и буфер, куда можно отдать байтики и откуда их считать. О том, чтобы положить или принять json (что часто происходит при веб-разработке), нет и речи. В наличии — самый низкий уровень, а нужны еще: соединение HTTP, REST API и веб-фреймворк, который умеет со всем этим обходиться и где можно удобно описать хэндлеры. Требуется нагородить кучу условностей, особенно если нужны промежуточные функции (читай: Middleware), которые агрегируют в себе сквозную функциональность. В Пайтоне с его обширной экосистемой проще: этот язык как будто и был создан, чтобы быстро и удобно писать веб-приложения, а также предостерегать программиста от ошибок, оставаясь при этом читаемым и понятным. При этом всем Пайтон не теряет в гибкости.

Ну и приятный бонус. Самый распространенный интерпретатор для Пайтон написан на C, поэтому для гиперпроизводительности можно делать вставки прямо на C-шном диалекте для Python (т. н. Cython), а можно взять чистый C и скомпилировать библиотеку для Пайтона — с теми же питоновскими интерфейсами, где при использовании не нужно запариваться о куче низкоуровневых вещей.

Минутка философии. Часто задают вопрос: какой язык круче и производительнее? Ответ есть. Стоит копнуть глубже, и становится понятно, что любой язык — просто обертка над C-шной утилитой или веб-сервером. Все меряются тем, насколько правильно они выбрали библиотеку на C и насколько хорошо с ней интегрировались. Поэтому нет особого смысла мучительно думать, какой язык круче. Если нужна мегапроизводительность, то лучше сразу писать на C. Либо на Rust, который появился сравнительно недавно, и с которым тоже можно отлично интегрироваться на Пайтоне.

К слову, о причине популярности Rust. Несмотря на то, что есть обкатанный аж с 70-х годов C, в нем все еще присутствует проблема восприятия кода и большая вероятность допустить ошибку в низкоуровневых вещах. Rust решил обе эти проблемы: его простой относительно C/C++ дизайн завоевал доверие большого количества программистов. В вопросах дизайна этот язык по пошел по пути упрощения так же, как когда-то Python. Да что уж там, даже новые стандарты знаменитого своей консервативностью C++ начинают учитывать положительную реакцию сообщества на подобные изменения. Это значит, что такой дизайн дорогого стоит.

О сравнении Python и Bash

Здесь стоит провести аналогию. Существует Python 2, с которого до сих пор активно пытаются слезть разработчики. Точно так же девопсы пытаются слезть с Bash. Но эти процессы не закончятся примерно никогда, потому что на том и на другом написаны тонны кода.

В СНГ первые девопсы произошли от системных инженеров и администраторов — людей с внушительным количеством опыта, которые по-настоящему шарят. Этим топовым дядькам уже солидное количество лет: они родились в эпоху Bash, и Пайтон в них не влезает. Потому что их голова и так вмещает гигантский объем знаний.

С одной стороны, это печально, потому что без постоянного развития в ИТ никуда. Но у этого есть логичное объяснение: когда становишься экспертом с вагоном навыков (кстати, независимо от возраста), трудно уместить в голове что-то новое. Это занимает много времени и сил, нужно ломать привычную модель мышления и начинать думать по-другому.

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

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

О сравнении Python и Go

Сравнивать языки программирования — все равно, что сравнивать глаз и молоток. Все-таки, глаз больше подходит, чтобы смотреть, а молоток — чтобы забивать гвозди. Можно попробовать и наоборот, но результат выйдет не самый лучший.

Для каждой задачи подходит свой инструмент. Если нужен высоконагруженный проект с жесткими требованиями к скорости обработки данных, то подойдет Go. Он более низкоуровневый и, как минимум, компилируемый. Обладая более высокой производительностью, этот язык обрел популярность в интернете вещей: здесь много устройств, которые генерят или обрабатывают большой поток данных в realtime.

Если нужно создать веб-приложение, которое выдержит 10–20 тысяч RPS, то Пайтон практически ничем не будет уступать тому же Go (под капотом все равно C-шный веб-сервер). Для бизнеса это может быть даже лучше, потому что на Python легче программировать с точки зрения отсутствия низкоуровневых сложностей. Поэтому R&D-подразделения, которым нужно сделать Proof of Concept, быстро проверить гипотезу, предпочитают Пайтон. Вместо того чтобы придумывать классную стабильную архитектуру на Go со всеми его концепциями, им проще написать на Пайтоне, проверить наличие отклика и написать что-то под большую нагрузку, пока приложение на Python держит нагрузку. А если таковая не предвидится, то просто переписать красиво на том же языке.

В каких отраслях нужен Python

Сегодня практически любая отрасль бизнеса делает веб-приложения, перекладывает json-ы из фронтенда в БД, так что Пайтон подойдет везде. Тем более, что его обширнейшая экосистема позволяет подобрать решение под конкретную отрасль. Парсить автомобильные номера по картинке — пожалуйста. Наскрэпить список онлайн-магазинов или подбор фотокарточек из Нельзяграма — как пожелаете. И далее по списку. Нет ничего, что нельзя сделать на Пайтоне быстро и удобно. За исключением низкоуровневого программирования, для которого он слишком медленный. Как и большинство языков, в принципе.

Пайтон быстро распространился среди девопсов благодаря наличию удобных инструментов. То же можно сказать о веб-разработке, потому что Time to Market никто не отменял, а у Пайтона есть обширная экосистема библиотек, которая позволяет разрабатывать быстрее. Но есть область, где Пайтон стал натуральным монополистом — Data Science. Здесь есть большое количество инструментов, которые позволяют с высокой производительностью обрабатывать и сканировать статические объемы данных.

Пайтон подходит разработчикам, девопсам и дата-сайентистам. Другими словами, всем ИТ-специалистам. Но не только им.

Случай из жизни. В одной из компаний работал юрист, которому был нужен Пайтон для работы. Он умел на нем неплохо программировать и применял для того, чтобы автоматически обрабатывать данные из договоров: получать, анализировать и складывать.

Сейчас будет спорное утверждение: любой язык программирования — это всего лишь инструмент для решения задачи, а не нечто, существующее изолированно и самодостаточно. Как и математика, в которой есть внутренние проблемы и противоречия, но в конечном итоге она тоже является абстрактным языком для описания реальных процессов. В этом контексте Пайтон выигрывает у многих языков за счет простоты входа. Его могут использовать практически все для абсолютно любых задач. Нужно раскидать сотни тысяч файлов по папкам? Написал скриптик за 10–15 минут и вполне счастлив.

Как Python помогает бизнесу

Первое — Time to Market. Если получается запрограммировать быстрее и допустить меньше ошибок на строчку, то бизнес быстрее отдает функциональность клиенту. На текущей работе Дениса клиенты — это внутренние подразделения, которые пользуются аналитикой. Аналитики готовят и отдают данные, а инженеры данных собирают информацию для аналитиков. Чем быстрее происходит сбор данных, тем быстрее бизнес может принять решение: увеличить бюджет, изменить стратегию и т. д.

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

Случай в рабочей практике

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

Таким образом разработка происходит еще быстрее. Если раньше условный разработчик тратил N времени на решение однотипной задачи несколько раз в месяц, то теперь он стал тратить 3N времени на разработку инструмента — и больше не тратит время на эту задачу вообще.

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

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

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

С помощью Пайтона компании автоматизируют задачи, которые годами делались вручную. Начиная с доступов через LDAP-системы в сервисы, которые это не поддерживают, заканчивая сбором метрик через кастомные Prometheus-агенты, которые изначально не поддерживали такой интерфейс.

Нужно учесть, что один только Пайтон не станет волшебной таблеткой для бизнеса. Языки в рамках одной компании — особенно крупной — нужно уметь комбинировать между собой. Благо, сейчас есть множество RFC-спецификаций о том, как правильно делать интерфейсы для взаимодействия программ друг с другом. Тот же REST API, где четко регламентируются HTTP-вызовы для взаимного обмена данными между программами и произведением вычислений.

Достаточное число компаний использует программирование на разных языках, чтобы применять конкретный язык там, где он лучше всего себя показывает. Если это Data Science, применяют Пайтон с интерфейсом REST API. Если это программа, которая работает с голым железом или требует производительности, используют C, Rust или Go — и точно так же через интерфейс получают и отдают обработанные запросы потребителю.

Случай в учебной практике

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

Она любила почитывать ЖЖ и выгружала оттуда статьи с комментариями. Для того чтобы это делать, существовала одна библиотека. Но она была прекомпилирована, и студентке пришлось пройти достаточно сложный технический квест, чтобы де-прекомпилировать библиотеку. В ходе работы она много узнала о внутреннем устройстве самого языка. Человеку пришлось изучить тонкости, известные далеко не всем серьезным веб-разработчикам, чтобы решить простую бытовую задачу.

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

Какие сложности есть на Python

У большой экосистемы языка есть обратная сторона: иногда документация просто не успевает за ее развитием. В C++, например, есть конечный и ограниченный набор библиотек. Для работы с json это, скорее всего, nlohmann/json. Она вообще не меняется из года в год, и программист точно знает: если загрузить это, библиотека отдаст то. Подобный алгоритм остается неизменным, меняется только скорость операций. В Пайтоне же может обновиться версия, даже незначительная ревизионная (с 2.4.0 на 2.4.1), а на поверку поменялось вообще все. При использовании новой версии библиотеки становится ясно, что она стала работать абсолютно иначе. При этом документация есть только на старую версию. Приходится самому разбираться. Возможный затык: другую версию использовать также нельзя, потому что разные библиотеки хотят разную версию одной и той же зависимости, а обратная совместимость потеряна. Можно запросто потерять весь каскад, за счет которого реализована логика в приложении. Такое встречается довольно часто, к сожалению. Поэтому иногда приходится читать сложный внутренний код с метапрограммированием, чтобы разобраться во внутренностях.

Еще одна потенциальная сложность может быть связана с последними событиями в России. Подобное уже произошло с «большой тройкой» облачных провайдеров у Terraform.

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

Мудрость дня: разработка сильнее объединяет людей, а не вносит раздоры среди них.

Заключительная мысля

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

Самый простой пример — работа с датой и временем. Люди привыкли сильно упрощать свое представление о физических и математических явлениях: в сутках 24 часа, в каждом часе 60 минут, в каждой минуте 60 секунд. Но мир устроен по-другому. Из-за гравитации солнца, проходящих рядом галактик и других внешних воздействий время не постоянно. Условно: каждые 4 года добавляется дополнительная секунда, каждые 10 лет — еще секунда, каждые 100 лет — 3 секунды. Соответственно, когда нужен точный учет времени, люди на этом спотыкаются и получают баг, который живет с ними всю жизнь.

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

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