Эта статья связана общей мыслью с предыдущей заметкой о документировании.
Если вы читали книгу Эдварда Йордана «Путь камикадзе», то вы наверняка помните его шикарную классификацию «безнадежных проектов». Я, конечно же, не буду пересказывать содержание книги, но в свою очередь хочу дополнить его список новым типом — это «старый безнадёжный проект».
Приходя в новую фирму, вы пытаетесь понять, с чем и c кем вам придётся иметь дело. Если вы попали именно на такой проект, то уже на первой встрече точно удастся распознать следующие симптомы:
1. Это «серьёзная международная компания».
2. Возраст проекта составляет 4+ года.
3. На проекте присутствуют бессменные «серьёзные специалисты», находящиеся на проекте в одной и той же должности в течение четырёх и более лет.
4. Компания не считает нужным обучать своих сотрудников в рабочее время («это личное дело каждого»).
5. Состояние и актуальность документации оставляет желать лучшего, если она вообще есть.
И при всём этом вам предлагают «развивать проект».
Что на самом деле это означает?
«Серьёзная международная компания».Это значит, что инвесторы, т.е. настоящие владельцы бизнеса, находятся далеко, и общение с ними может быть затруднительным. Ничего особо плохого в этом нет, но если инвесторы редко общаются с командой, то, вероятно, их мало интересует что-то кроме прибыли. А такой подход порождает как следствие все остальные проблемы.
Солидный возраст проектаможет говорить о двух вещах: во-первых, он должен быть достаточно прибыльным, чтобы просуществовать такое длительное время, а во-вторых, в проекте типа «старый безнадёжный» вас ждут тонны сильно связанного макаронного кода — я гарантирую.
Почему так происходит?Потому что команда, начавшая проект, не потрудилась должным образом организовать процессы девелопмента и придерживаться их (в частности, не проводили своевременный рефакторинг), а менеджеры и руководство — не особо интересовались процессом разработки: «Сделай всё что угодно, но чтобы к понедельнику эта фиговина была готова!» — «Но как же рефакторинг? Мы не сможем так просто впилить эту фичу, нам придётся делать костыль!» — «Меня не интересуют эти твои программистские штучки, мне нужен результат!» — «Ну ок, будет сделано». — И эта ситуация продолжается бесконечное количество раз.
Собственно, подобные проекты безнадёжны с точки зрения развития. Да, они могут приносить деньги, но они не эволюционируют. А разработчики, надолго ввязавшиеся в эту авантюру, — закисают, медленно деградируют, уверенно скатываясь в состояние технологических ретроградов. Зато стабильность.
Любая фирма заинтересована в том, чтобы её ценные специалисты оставались на проекте как можно дольше. Но в данном примере это только один симптом из всего комплекса.
Когда руководство не интересует ничего, кроме «фиговины, которая должна быть готова к понедельнику», то его, разумеется, не будет интересовать и профессиональный рост команды разработчиков. Такие компании не считают необходимым всячески стимулировать своих разработчиков к обучениюновым подходам и технологиям.
В результате мы получаем не просто программиста, который сидит на одном месте годами — со временем, вследствие отсутствия обучения новому, он просто теряет свою квалификацию.
Так как на документирование времени сначала тоже нет, а потом руководству всё равно «это не интересно», то наш неквалифицированный старожил-ретроград превращается в «незаменимого» сотрудника, ведь только он знает, что происходит внутри проекта и как оно работает. А документации нет.
Все эти нездоровые процессы являются симптомами одной и той же болезни, которая называется «и так сойдёт». Да, да, этот проект тяжело и хронически болен. И вот в таких условиях вам предлагают «развивать»:
«Эй, Джо, пришей пациенту ногу.» — «Но зачем? Пациент ведь мёртв. И что это за дурацкое имя в карточке — Франкенштейн?» — «Мы слишком долго работали над ним, чтобы так просто бросить. И вообще, что за претензии — сказали пришить — значит пришей, и не задавай дурацких вопросов!»
Какое будущее ждёт вас?
Всё очень просто. Если взять свежий огурец и положить его в банку к солёным — он довольно скоро станет солёным. Если свежий огурец положить к гнилым огурцам — он тоже быстро станет гнилым. А всё потому, что эти огурцы подверглись действию формирующей среды, которая сделала их будущих.
Очень внимательно следите за своим профессиональным окружением.
Чтобы оценить масштабы распространения такой «корпоративной культуры», достаточно вспомнить, как часто в описании вакансий мы читаем: «терпеливое отношение к чужому коду». Эта кодовая фраза означает, что вам предлагают поработать, простите, с быдлокодом.
Соглашаться на такую работу стоит только в том случае, если вы твердо уверены, что лучшего предложения в своей жизни вы точно не найдете. Или же тогда, когда руководство честно заявляет, что текущая ситуация их не устраивает и стандарты девелопмента в ближайшем будущем будут пересмотрены — а вы один из тех счастливчиков, которые будут этому способствовать. Бывает и такое.
Если же каким-то непонятным образом вас уже занесло на такой проект, то, во-первых, хочу искренне посочувствовать, а во-вторых, раз уж вы там, то хотя бы попробуйте от души насладиться концентрированным действием эффекта Даннинга-Крюгера. Потому что старые «незаменимые» сотрудники будут отчаянно сопротивляться любым изменениям и как «более опытные» постараются наставить вас на путь истинный.
Какое будущее ждёт сам проект?
На самом деле, несмотря даже на команду «высококлассных незаменимых сотрудников», чтобы угробить крупный проект, нужно постараться.
Возможно, медленно, коряво, но всё же свои функции он выполняет. Пока. Основная сложность заключается в скорости сопровождения такого проекта. Его очень сложно развивать.
Если у продукта на рынке практически нет конкурентов, например, потому что он обслуживает какую-то крупную монополию (международные корпорации или госструктуры) — такой проект можно считать «условно вечным». Он никогда не будет модернизирован до тех пор, пока код не превратится в совершенное макаронное месиво, от которого будут воротить нос даже самые матёрые гуру рефакторинга.
Жизненный цикл таких проектов:
1. В спешке программисты создают продукт. Всё хорошо, разработка идёт быстро.
2. По мере накопления строк кода проект делается всё неповоротливее и запутаннее. Но проектная команда всё равно торопится, код запутывается всё больше.
3. Происходит наращение штата разработчиков, потому что скорость сопровождения катастрофически падает, а решать эту проблему иначе руководство не способно. Новые программисты, попадая в этот бардак, ещё меньше понимают «архитектуру» системы, и в спешке вынуждены загромождать проект всё большим количеством костылей.
4. Разработка превращается в «костыль-менеджмент». Проект выходит из-под контроля. Всё, конец, epic fail: вносить хоть какие-то значимые изменения больше не представляется возможным, потому что проект рассыпается от малейшего прикосновения, как старая слоёная печенька. Это настоящий проект-франкенштейн, у него нет чего-либо похожего на архитектуру, — просто каша непонятным образом связанных фрагментов.
Наличие конкурентов только ускоряет ваш конец, особенно если они следят за качеством кода, который пишут их разработчики. В их продукт, в отличие от вашего, изменения вносятся регулярно и качественно, и вас вытесняют с рынка.
Что можно сделать с таким проектом?Первое: попытаться отрефакторить, если это ещё возможно. Второе: переписать заново. Но в этом решении есть свои «комплексные грабли», о которых я напишу в следующий раз.