Преамбула
Давайте представим, что вас попросили возглавить одно
из направлений в вашей компании. Вы, конечно же, знаете всех людей в
команде, неоднократно пересекались в коридорах и пили пиво на
корпоративах. Прошлый руководитель был неплохим человеком, но у него
изменились планы и он уволился.
И вот, вы, принимая пост,
знакомитесь с командой: вроде бы есть потенциально сильные разработчики с
опытом, есть несколько подающих надежды юниоров. Но что-то сразу
бросается в глаза. И чем дольше вы вглядываетесь в эти занятые работой
умные лица, тем более понимаете, что перед вами не команда, а «группа
разработчиков». А то, что они пишут… Вы и не думали, что программисты
могут так писать код. Вы смотрите на пластилиновую архитектуру, на
классы в 6000 строк кода, на методы, занимающие десять страниц
машинописного текста, на кейсы, ветвящиеся как головы Лернейской гидры. И
у вас появляется невольный вопрос: а можно ли что-то с такой командой
сделать вообще?
И мой ответ — можно. И нужно!
Осознание
Итак,
с чего начать? Начать надо с понимания того, что никто и никогда
сознательно не пишет плохо. Вероятнее всего, предыдущий руководитель
либо совершенно не следил за качеством кода его подопечных, полностью
сосредоточившись на текущих финансовых показателях и планах, либо
сознательно приносил качество кода в жертву тем же самым текущим
финансовым показателям.
Я специально сделал упор на слово
«текущим». Плохой код, в любом случае, со временем встанет на пути
дальнейшего развития продукта и сделает его поддержку не только адом для
заказчиков и программистов, но и крайне убыточным для компании делом. В
этом случае, ваша фирма, вместо того, чтобы инвестировать в развитие,
вынуждена будет вкладывать огромные суммы в исправление ошибок и
поддержание жизни умирающего под тяжестью собственного внутреннего
безобразия продукта. Либо тратить ресурсы на написание новых версий
продукта, который, при должном подходе, мог бы ещё долго жить и
приносить прибыль бизнесу и радость разработчику.
Вообще, для
того, чтобы сложившиеся программисты вдруг стали писать правильно, нужно
либо чудо, либо долгая кропотливая работа. Несмотря на любой ваш
оптимизм, я рекомендую выбрать второй путь. Этот путь состоит из трёх
неравных шагов, которые я раскрою ниже.
Помните, что Ивана
Царевича в сказках, оживляя, сначала поливали мёртвой водой и только
потом живой. Вероятно, в конце он женился на какой-нибудь Василисе
Премудрой. В разработке ПО примерно так же.
Шаг первый. Ненависть
Вероятно,
это наиболее спорный тезис из всех, которые я буду здесь приводить. Со
мной часто не соглашались (доходило до перехода на личности и обиженного
сопения в углу), но эффективность его проверена на практике.
Итак,
в самом начале программистам нужно привить ненависть. Ненависть к
плохому и грязному коду, к глупым ошибкам, к кейсам в пятьсот строк и
классам, состоящим из одного метода размером с дом.
Как это
сделать? Начните проводить открытые инспекции кода. Собирайтесь всей
командой раз в неделю, и пусть кто-нибудь ищет в коде грязь и
антипаттерны. Если у вас есть навыки отличить плохой код от хорошего —
участвуйте в них сами, если нет — просите того, кому вы в этом отношении
доверяете.
После нескольких таких ревью программисты, вероятнее
всего, уже будут понимать, что такое магическая кнопка и откуда вызвать
рефакторинг «вынести метод». Ещё раз: исходите из того, что плохой код
писать никто не любит. Просто многие не понимают, что он плохой.
И
ещё: не переходите на личности (кто написал ЭТО? Вася? Вася, как тебе
не стыдно? Останешься без премии!). Но плохой код не щадите. Я считаю —
совершенно нормально осведомиться «с какой целью в код был залит этот
дамп подсознания». Потому, что код — дрянь. Потому, что программисты
этого не понимают, пока не скажешь. Это жёстко, но эффективно.
Шаг второй. Страсть
Покажите
программистам паттерны, примеры хорошей архитектуры и красивый код.
Заразите их этим. Пусть они кидаются умными словами типа «фабрика» и
«декоратор», осознавая свою профессиональную компетентность, а их код
изобилует никому не нужными стратегиями и ничего не вызывающими
шаблонными методами. Сделать этот шаг проще, но делать его надо примерно
в одно время с первым. Пусть они конструируют, мыслят и упиваются
фактом своего знания теоретических основ архитектуры ПО. Это только на
пользу и, между прочим, очень мотивирует.
Но главное, что надо
осознать — ни в коем случае нельзя останавливаться на этом шаге,
несмотря на то, что он кажется очень заманчивым и создаёт ощущение
работы с командой профессионалов.
Шаг третий. Здравомыслие
Теперь,
когда ваши программисты умеют уловить запах, идущий от протухшего кода,
и сконструировать фабрику по созданию оконных интерфейсов разных
цветов, самое время подумать о главном — о реализме. Объясните ребятам,
что паттерн проектирования применяется только в нужном месте и нужном
времени, метод может состоять и более, чем из двух строк, а строковые
константы в тексте, в общем-то, иногда допустимы. Объясните, что, прежде
всего, надо писать простую и прозрачную стабильно работающую систему, а
уже потом «совершенное архитектурное решение, на 93% покрытое
паттернами проектирования».
Это сложнее всего. Сложнее всего
объяснить, почему «дамп подсознания в код» — это сложно, но не менее
сложна и реализация фабрики по созданию константных строк для подписей к
кнопкам (будем считать, что локализация не предусматривается). Но
избавляться от этого надо. Не сделать этот шаг означает оставить
программиста в вечной уверенности, что он пишет хорошо и разбирается в
архитектуре тогда, как пишет он немногим лучше, чем раньше, а его архитектурные решения заставляют схватиться за голову. И это беда для любой команды.
Пара слов в заключение
Ну собственно, и всё. Могу только сказать на своём опыте, что «ненависть» и «страсть» прививаются примерно за полгода, а на доведение шага «Здравомыслие» иногда уходит больше двух лет, и оно приходит вместе с опытом. И приготовьтесь, что ваши «текущие финансовые показатели», вероятно, просядут на некоторое время. Но полученная взамен команда, умеющая создавать лёгкий, аккуратный код, подходящий для длительной поддержки и расширения, на мой взгляд, стоит этих инвестиций.