CI driven development

Попросили разместить.

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

Никому не нужны специалисты просто со знанием определённой технологии. Требуются именно спецы с коммерческим опытом на ней. Иногда это доходит до абсурда: я видел, как создатель какого-то очередного HTTP-фрэймворка запостил у себя в Twitter’e скриншот вакансии, в которой опыта с его собственной технологией требовалось больше, чем то количество времени, которое она в принципе существует. Т.е. автор фрэймворка не смог бы даже пройти автоматический HR-фильтр, не наврав в резюме. Это выносит мозг.

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

Всё это и приводит нас к феномену, известному как CI driven development. Это такой подход, при котором выбор технологии для реализации фичи обусловлен не какими-то объективными причинами, а в первую очередь желанием получить нужную строчку в резюме, чтобы в будущем перейти на более вкусную позицию уже в другой компании или банально не выпасть из рынка труда из-за неактуального стэка. В итоге на проектах скапливается нехилый такой зоопарк технологий, которые придётся поддерживать уже кому-то другому (а предыдущий разраб свою задачу по получению строчки в резюме уже и так успешно выполнил и съебался). Также причиной такого является то, что некоторым всё же не хочется жертвовать свободным временем на изучение всякого хлама, а вместо этого познать всё прямо во время внедрения. Да и учитывая количество сверхурочной работы в IT, не у всех это самое свободное время есть зачастую.

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

Внезапно, у данного явления пара плюсов всё же есть:

1. проект действительно может разрастись до такой степени, что завезённые в него технологии станут актуальны. Хотя гипотетически произойти вообще может всё что угодно. И при этом чисто статистически более вероятным является закрытие проекта, а не его разрастание;
2. поскольку технологии в IT постоянно устаревают и выкидываются на свалку, необходимо регулярно обновлять стэк проекта. “Да пое@ать мне на новые технологии, пускай проект продолжает работать на старых, а на карьеру мне по@уй”, — можете сказать вы. Но тут проблема в том, что выброс технологии на свалку подразумевает прекращение её поддержки. Можете забыть о том, чтобы кто-то вам пофиксил критические баги или добавил поддержку чего-то действительно нужного.

В итоге напрашивается вывод, что CI driven development — это скорее нормальное и необходимое явление в сфере IT, обусловленное фундаментальными проблемами разработки ПО. Прямо как Scrum. Ну и оба приносят разработчикам огромное количество стресса, головняка, выгорания, технических сбоев и т.д. Увы, таковы реалии в данной сфере.