Revive image via Shutterstock.Если у вас есть старый безнадежный проект, перед вами неизбежно рано или поздно встанет вопрос: что с ним делать дальше? Потому что такой проект всё больше напоминает ненасытного прожорливого монстра: скорость его сопровождения неумолимо падает, а стоимость обслуживания неприлично быстро растет.
Муки выбора: починить или сделать новое?
Существует два диаметрально противоположных мнения по этому вопросу. Топы и прочие менеджерычасто убеждены, что старый код нет нужды переписывать, потому что «пока мы будем переписывать систему — конкуренты вырвут инициативу и заберут всех наших клиентов». Менеджеров мало интересуют технические детали вопроса, их задача — монетизировать продукт и считать деньги. Они свято убеждены в том, что начать переписывать систему — это получить гарантированный фриз («заморозка» живого проекта — невозможность внесения каких-либо изменений).
С другой стороны баррикад давят технические специалисты, акцентируя внимание на том, что система катастрофически устарела, её сложно и неинтересно сопровождать. И если ничего не поменяется, то спустя некоторое время проект станет колом. Инженеры в первую очередь заинтересованы в простом и понятном сопровождении проекта, их мотивирует работа с современными технологиями. Они знают, что если оставить всё «как есть» — это неминуемо приведёт к фризу в обозримом будущем.
Обе стороны опасаются одного и того же, но по-разному понимают причины потенциальной остановки проекта.
Что происходит дальше: все инициативные технические специалисты, будучи не услышанными, уходят. Скорость сопровождения системы продолжает экспоненциально падать. Более сообразительные конкуренты систематически вносят обновления и новшества в свои продукты, отбирая ваших клиентов. К этому моменту руководство наконец-то принимает волевое решение: «Нужно что-то делать!»
И первое, что нужно решить, — это какой из вариантов вам больше подходит: глубокий рефакторинг или же «переписывание с нуля». Универсального совета в выборе между этими двумя вариантами нет — всё зависит от тяжести каждой отдельно взятой ситуации. Но прежде чем выбирать — проведите консультациисо сторонним системным архитектором и аналитиком. Эти люди могут направить вас на нужный путь.
А как же получаются хорошие проекты?
Прежде чем продолжать рассуждения о головной боли старых безнадежных проектов, давайте немного отвлечемся и обратим внимание на успешные IT-продукты. Их все объединяют общие качества:
1. Культура обмена информацией, обучение и условная заменимость.Участники проекта активно обмениваются информацией, обучают друг друга, обучаются сами. Ваш руководитель открыто и с удовольствием рассказывает о результатах последних встреч. Разработчики постоянно интересуются делами друг друга и могут в любой момент подменить не вышедшего на работу сотрудника. А «вон тот парень из продуктового отдела» даже понимает, что такое «рефакторинг / полиморфизм / наследование», хотя он не программист и знать этого не обязан.
2. Системный подход.Практически все процессы девелопмента имеют цикличный характер и подчиняются установленным правилам, будь то стандарты кодирования, тестирование, рефакторинг, кодревью, методология разработки или документирование. Даже обучение участников проекта поставлено «на поток».
3. Высокий уровень личной ответственности.Сотрудники лично мотивированы и настроены на профессиональный рост, в команде есть участники, которые берут на себя ответственность за принятие решений.
В старых безнадежных проектах, несмотря на их солидный возраст, сходу можно найти с десяток «незаменимых сотрудников», без которых немыслимо сопровождение некоторых частей проекта. Потому что никто не знает, как оно работает.
А о системности подходов ярко говорит случайным образом связанный макаронный код проекта и отсутствие каких бы то ни было стандартов.
Очень часто в таких компаниях процветает «корпоративный пинг-понг» — чтобы решить любую проблему, нужно обойти пять кабинетов и потратить полдня времени.
Без чего вы точно не обойдетесь
Чтобы в корне изменить ситуацию, вам в основном понадобятся две вещи: политическая воля и «новая кровь».
Политическая воля. Пытаться изменить ситуацию коренным образом, не имея при этом поддержки руководства, — затея бессмысленная. Но, несмотря на всю очевидность этого факта, многие разработчики считают, что они в состоянии повлиять на систему «собственным примером». Их план прост и незатейлив:
1. Красиво и идейно писать код.
2. Это увидят все остальные, оценят и поймут, как это круто и удобно,
3. и начнут сами писать так же.
Мечта прекрасная, и настолько же несбыточная. На самом же деле авторы макаронного кода продолжат ваять свой адский продукт, а «фантазёрам-трудяжкам» отдадут самые тяжелые и запущенные закутки Авгиевых конюшен проекта.
Почему без политической воли руководства невозможно сдвинуть с места этот камень? Потому что изменения должны произойти не только в коде проекта, а в самом подходе к формированию процессов разработки ПО. Изменения должны быть проведены системно и повсеместно. Одному разработчику, — даже группе — эта задача не под силу, в данный процесс должны быть вовлечены все участники.
«Новая кровь». Если бы старые разработчики системы могли сделать что-то «получше», они бы это делали. Поэтому без привлечения в проект новых людей с отличными знаниями современных технологий, подходов и высоким уровнем мотивации вам не обойтись.
Что же вас ждет? Если вы «старый» разработчик на проекте, и вас попросили остаться при обновлении — придется учиться. И это хорошая новость, потому что с новыми умениями вы увеличите свою ценность на рынке труда. Начинайте прямо сейчас!
Если вы занимаете руководящую должность и решились на перемены, изучите особенности функционирования IT. Разработка — фундамент вашего бизнеса, и вы должны разбираться в его основах.
Если вы — тот самый представитель «новой крови», вас ждет много интересных задач и высокооплачиваемый адский труд.
Но это еще не всё.
Во второй части беседы поговорим о тимбилдинге в старых безнадежных проектах.
Сердечно благодарю Славу Конашковаза профессиональные консультации и помощь в написании этой статьи.
Продолжение: Как реанимировать старый безнадежный проект. Часть 2: Тимбилдинг