Три шага команды к совершенному коду (+ видео на эту тему)

Преамбула

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

И вот, вы, принимая пост, знакомитесь с командой: вроде бы есть потенциально сильные разработчики с опытом, есть несколько подающих надежды юниоров. Но что-то сразу бросается в глаза. И чем дольше вы вглядываетесь в эти занятые работой умные лица, тем более понимаете, что перед вами не команда, а «группа разработчиков». А то, что они пишут… Вы и не думали, что программисты могут так писать код. Вы смотрите на пластилиновую архитектуру, на классы в 6000 строк кода, на методы, занимающие десять страниц машинописного текста, на кейсы, ветвящиеся как головы Лернейской гидры. И у вас появляется невольный вопрос: а можно ли что-то с такой командой сделать вообще?

И мой ответ — можно. И нужно!

Осознание

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

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

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

Помните, что Ивана Царевича в сказках, оживляя, сначала поливали мёртвой водой и только потом живой. Вероятно, в конце он женился на какой-нибудь Василисе Премудрой. В разработке ПО примерно так же.

Шаг первый. Ненависть

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

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

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

После нескольких таких ревью программисты, вероятнее всего, уже будут понимать, что такое магическая кнопка и откуда вызвать рефакторинг «вынести метод». Ещё раз: исходите из того, что плохой код писать никто не любит. Просто многие не понимают, что он плохой.

И ещё: не переходите на личности (кто написал ЭТО? Вася? Вася, как тебе не стыдно? Останешься без премии!). Но плохой код не щадите. Я считаю — совершенно нормально осведомиться «с какой целью в код был залит этот дамп подсознания». Потому, что код — дрянь. Потому, что программисты этого не понимают, пока не скажешь. Это жёстко, но эффективно.

Шаг второй. Страсть

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

Но главное, что надо осознать — ни в коем случае нельзя останавливаться на этом шаге, несмотря на то, что он кажется очень заманчивым и создаёт ощущение работы с командой профессионалов.

Шаг третий. Здравомыслие

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

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

Поэтому, здесь придётся приложить максимум усилий, чтобы объяснить, почему раньше было «фабрика — это хорошо», а теперь «фабрика — это плохо». Но я уверен, они окупятся сполна.

Пара слов в заключение

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

Бонус

"Home-video" моего рассказа на эту тему, нагло украденное мной из блога компании Сибирикс. И соответствующие слайды.

как воспитать программиста (Выступление в Sibirix)

View more PowerPoint from Mikhail Payson