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

Как становятся экспертами

Чтобы объективно понять, почему в обозначенных вопросах до сих пор нет ясности и ведется столько «религиозных» споров с человеческими жертвоприношениями, нужно отвлечься, улыбнуться и прочертить кухонным ножом жизненный путь IT-специалиста в виде ломаной линии на столе с квадратиками, означающими полученные знания.


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

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

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

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

Копипаст, фреймворки и научная фантастика

Очевидно, что так самоотверженно учиться и познать Истину могут лишь единицы и в реальной жизни встречи и споры о технологиях и языках программирования происходят, в основном, между фанатами разных и модных «сериалов», не знающих, часто, разницу между IP и TCP. Проблема усугубляется внешним агрессивным маркетингом — большинство крупных IT-вендоров активно «вербуют» последователей в свои ряды, используя прокачанные информационные каналы. За примерами далеко ходить не нужно — Mozilla пиарит Rust, Google продвигает Go, Oracle заинтересован (?) в продвижении Java, Microsoft развивает C#, JetBrains — Kotlin, инопланетяне — Haskell, а научное сообщество не нарадуется, когда под видом AI и ML, нейронок и датасатанизма, за большие деньги продаются… пыльные академические курсы по теории вероятностей, линейке и матстатистике во веки веков, аминь :-)


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

Традиции и «правильность»

Дело в том, что собрать, например, автомобиль из железа — достаточно дорогое и долгое занятие: нужен материал, сварка, знания, помещение, плакат девушки с правильными формами и т.п. А написать программу, особенно не в одиночку — дело вполне распространенное. Виртуальное творчество — взорвало и продолжает комкать и растягивать мир. Море цифрового контента, часто бестолкового и примитивного, где все писатели и художники, заполонило сеть. В результате относительной простоты «самовыражения», в мире, за относительно короткий промежуток времени, после Второй мировой, появилось огромное количество не только программ, но и языков программирования. Написать новый язык программирования — несложно, гораздо сложнее — чтобы он завоевал популярность. Так исторически сложилось, что популярными сейчас являются языки, на которых учились «их правильно писать» (например C++, Java, ECMA262), а языки, которые «сделали потом и, вроде, лучше» (например C#, Python3, Rust, Kotlin), популярны в гораздо меньшей степени. Выбирая «более правильный» язык, вы рискуете не найти достаточного количества знающих его разработчиков или может случиться так, что язык просто перестанет развиваться или вознесется в вечность, как Haskell. Поэтому, руководствуясь здравым смыслом, нередко выбирают традиционные, так сказать, технологии, пусть даже не совсем «правильные» и непротиворечивые, полные костылей и следов взросления, но зато проверенные, популярные и развиваемые.


В контексте активной разработческой графомании (особенно в направлении фронтенда, хотя и в npm тоже весело) хочется предостеречь от бездумного использования библиотек и фреймворков. Важно посмотреть на историю развития фреймворка, контингент разработчиков (чем проще технология, тем сюрпризов больше) и продолжительность поддержки версий.

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

Коммерческие библиотеки и фреймворки, обычно, подобной детской болезнью не страдают (правда не все, нужно тщательно смотреть в документацию и изучать этот вопрос досконально) и поддерживают обратную совместимость 5 и более лет. Обратите, пожалуйста, на это особое внимание, иначе придется ВДРУГ переписывать ваше веб-решение почти с нуля!

В общем, по этому пункту, лучше пользуйтесь пословицей про синицу и журавля.

Новое или… готовое

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


Хорошей ассоциацией может быть выбор базы данных — что взять для веб-проекта, БД Oracle или БД MySQL (да, я знаю, что они теперь развиваются одной компанией). По опыту — 99% задач веб-разработки, даже под высокими нагрузками, отлично и в высокой скоростью решается в MySQL. А если результат не отличается, зачем ...? :-)

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

Сложно и долго или… быстро и просто?

Это тоже известная причина многочисленных и бесконечных споров. На самом деле современные IT-технологии и языки программирования делятся, грубо, на 2 части: простые для большинства (не нужно глубоко вникать, несколько дней на понимание) и сложные для меньшинства (нужна серьезная и долгая специализация, месяцы на понимание). Как мы увидели выше, большинство учиться не любит, поэтому внедряя может и правильную и надежную технологию — вы не преуспеете по причине того, что с ней никто до конца не разберется и вы будете играть в русскую рулетку с черным ящиком. Популярный пример: выбор между redis или cassandra — продукты разного порядка сложности. Или, другой пример: python или C++.

На простых языках, действительно, программировать, часто, гораздо, на порядки, быстрее — сравним скрипт на python из 5 строк и аналогичный код на C на 100 строк. Но, обычно, «простые» языки и универсальные технологии работают иногда существенно медленнее и потребляют гораздо больше оперативной памяти :-) Ведь за все нужно платить.


Тем не менее, «простые» языки все чаще и чаще используются для решения большинства задач программного проекта, где особые требования к супер-скорости и оперативной памяти не нужны. И железо дешевеет и дешевеет. PHP сейчас очень популярен для быстрой веб-разработки, а python, с его очень ясным и читаемым синтаксисом — для общих задач и машинного обучения. JavaScript очень удобен для автоматизации не только веб-интерфейса, но и… создания действительно быстрых серверных приложений на Node.js. Go, даже с его примитивным синтаксисом, позволяет обходиться в системных задачах без более мощной, но гораздо более трудной в понимании Java, а мобильное приложение можно быстро создать на на порядки более простом и доступном начинающим путь в разработке Kotlin. Можно с гораздо меньшими рисками запустить хайлоад приложение на Rust, не вникая в тонкости управления памятью в C++. Но никто, в здравом уме, не будет писать игру на Java, вспоминая популярный minecraft, в который можно играть только на расстоянии 10 метров от дисплея, прищурившись :-)

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

Комично, но в текущих реалиях, даже не выбор языка, а выбор возможностей языка может оказать решающее влияние на успех. Например, имея команду, у которой нет опыта объектно-ориентированного программирования и знания шаблонов проектирования, можно написать такой вопиющий объектный зоопарк, что, возможно было бы проще решить задачу 100 функциями в одном монолитном файле, понятном всем, чем скрываться в офисе от сотен объектных монстров с тумбой вместо головы и ушами вместо ног. Именно поэтому, часто, простые языки (типа python, php, javascript, ruby), не предоставляющие избыточных возможностей для разработческой графомании и перфекционизма, ориентированные на ясность, однозначность (python) и лаконичность (php), позволяют все чаще приходить к успеху. Не зря же так популярны истории, когда веб-сайт начинали делать на C++ и каким кошмаром потом это обернулось.

Хорошей аналогией тут является пример дорогих и сложных в «настройке» рыцарей средневековья и… хулиганов с огнестрельным оружием. Можно всю жизнь тренироваться и стать самураем многопоточной Java, но скоропостижно завершить свою жизнь при встрече со школьником с аналогичным и на порядке более простым решением на python или Go.

АрхитектУры и архитектОры

Действительно, лет 10-15 назад нужно было долго учиться и читать толстые книжки, чтобы понять принципы размещения объектов и их взаимодействия на отдельных серверах и кластерах (j2ee, corba, com). Отголоски этого бума на архитектуру и архитекторов и до сих пор можно встретить в монстроподобных творениях типа Spring. Но времена меняются, технологии становятся мощнее и доступнее. Развернув пару-тройку бесплатных веб-серверов Apache, БД MySQL, очередь RabbitMQ где нибудь в Амазоне, можно решать большинство задач, доступных ранее в понятных подавляющему меньшинству конфигурациях серверов приложений.


Если стоит задача поддержки массовых сетевых соединений, можно поднять кластер Node.js машин или, скорее лучше, машин с Erlang и спать спокойно, чем писать собственное серверное решение на, например Go или C++.

Если нужно заниматься исследованиями, постоянно, в потоке, отбирая из 10-20 моделей машинного обучения одну и быстро их разворачивать в облаке для обслуживания клиентов, то, несомненно, очень удобным и практичным решением тут станет python с огромным количеством библиотек и так далее.

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

Подбор команды

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

Однако, в нестандартных проектах, придется найти минимум одного разработчика, знающего что-то еще и отлично, кроме python, ruby, php, javascript, go, perl, bash, шансон. Шансы, что боец хорошо знает алгоритмы, шаблоны проектирования, сетевые стандарты, ООП — значительно повышаются.


Если проект связан с машинным обучением и нужно что-то углубленно копать, придется найти настоящего аналитика-математика, желательно с научной степенью и знанием python. Я серьезно — для машинного обучения, без профильного образования, нужно напряженно учиться по несколько часов в день (теория вероятностей, линейная алгебра, метод наименьших квадратов, матстатистика, теорема Байеса и его техники) несколько месяцев, если не лет.

Процессы или технологии?

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

• предварительное проектирование, нагрузочные испытания и анализ рисков
• автоматизированное юнит и интеграционное тестирование (желательно 100% покрытие)
• единые стандарты кодирования
• хорошее документирование кода и компонентов системы
• максимально прозрачные коммуникации внутри команды
• мониторинг и аналитику серверного окружения

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

Итоги

Подведем итоги и расставим приоритеты:

• Все чаще можно наблюдать ситуацию, когда именно скорость запуска программного проекта является решающим фактором успеха. Долго и напряженно делать что-то ненужное хуже, чем быстро выпустить решение, полезное для клиентов и собрать обратную связь для следующего рывка
• Быстрый запуск возможен только при использовании максимума готовых составных элементов, фреймворков и библиотек с адекватным сроком поддержки (с учетом ожидаемого времени жизни вашей веб-системы)
• К сожалению, алгоритмические и архитектурные знания востребованы все реже. Чаще приветствуется опыт решения похожих задач и практика использования комплексов инструментов и сильных сторон облачных провайдеров.
• Не нужно ограничивать себя и все делать на одной технологии и только одном, ЛУЧШЕМ, языке программирования — огнестрел в руках ребенка эффективнее изучения боевых искусств самураем всю сознательную и бессознательную жизнь. Перфекционизм и идеализация убивают программные системы. Выбирайте верное оружие для каждой задачи в проекте. Берите готовое и сосредоточьте оставшиеся усилия на нестандартном.
• Выбранные технологии должны быть простыми, понятными и доступными большинству в команде. Посмотрите, на чем пишут подобный проект в основном и возьмите этот стек технологий себе. Не автоматизируйте хостинг хаскелем и не пишите веб-сайты на C++ :-) Если ваш проект «взлетит» и начнет развиваться, только тогда можно рассмотреть возможность переписывания его небольших частей на более сложных технологиях и языках программирования. Но обычно до этой стадии программные проекты либо не доходят, либо доходят через несколько лет.
• Фреймворк позволяет на порядки ускорить запуск программного проекта. Обязательно проверьте наличие хорошей документации и уточните срок поддержки фреймворка, чтобы не случилась беда с полным переписыванием через 2-3 года. Это очень частый кейс у наших клиентов.
• Не верьте в способности команды учиться — в жизни слишком много отвлекающих факторов и ситуация только усугубляется. Внимательно изучайте резюме, проверяйте сертификаты и сданные экзамены и постарайтесь максимально сосредоточиться на практическом результате. Ставьте практику выше теории, хотя бы на время создания первой версии работающего решения.
• Технология и язык(и) программирования не являются определяющими факторами успеха. Сосредоточьтесь на выстраивании самых необходимых процессов и внедрении ключевых практик разработки и проектирования. Правильные процессы, как правило, гарантированно приводят к «правильному» результату. Связавшись с «сектантами чистой технологии» или «попав на науку», вы потратите кучу времени впустую и можете так ничего и не запустить. Помните, 2-3 месяца это максимум для запуска в бой очередной итерации программного проекта.

Всем удачи, успешных проектов, адекватных команд и отличного настроения!