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