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