воскресенье, 18 марта 2012 г.

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

Преамбула

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

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

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


Осознание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



3 комментария:

  1. Опять упомяну принцип high cohesion and low coupling. Научите понимать, что такое cohesion и что такое coupling. Научите всех в команде (не только программистов) отличать высокий cohesion от низкого, а также низкий coupling от высокого. Покажите на примерах насколько решения с высоким cohesion и низким coupling отличаются в лучшую сторону от решений с низким cohesion и высоким coupling. За примерами последних решений далеко ходить не нужно. Достаточно заглянуть в текущий код. Объясните, что конечная цель любого рефакторинга - это повысить cohesion и понизить coupling. Повысить и понизить ровно настолько, чтобы это позволило добавить новую функциональность не потеряв в cohesion и coupling. Все остальное приложится. :)

    ОтветитьУдалить
    Ответы
    1. Алексей, спасибо за отличное практическое дополнение!

      Удалить
  2. Для тех кто далек от построения процессов разработки и архитектуры ПО, поясню. Решения с высоким cohesion и низким coupling получаются более структурированными, собранными из более независимых друг от друга компонент. Это делает их со временем все более выгодными в поддержке и развитии. В качестве примера можно привести автомобильную отрасль. Автомобили собираемые из более стандартизованных компонент дешевле в разработке и производстве. Главное - не забывать при этом об общем качестве продукта и уделять должное внимание тестированию. :)

    ОтветитьУдалить