История 16. «Делаем все по правилам!»
Симптомы:
- Программист стремиться сделать наиболее общее решение задачи, учесть все возможные последующие изменения и расширения.
- Старается разработать самый быстрый алгоритм, требующий минимальных ресурсов.
- Использует в решении все лучшие практики, паттерны проектирования, самые новые инструменты.
Диагноз. «Зло преждевременной оптимизации». Причина: программист не научился управлять приоритетами. Не различает важные и не важные дела. Низкая эффективность. Для решения задач в срок постоянно не хватает времени. Сверхурочные. Раздражительность. В результате появляется большой и проблемный код.
Рекомендации. Более четко формулировать цели и расставлять приоритеты. Определить конкретные критерии оценки результата, директивное управление. Нацеливайте программистов на правильное решение задачи максимально быстрым способом. Опыт свидетельствует, что более чем в 90% случаев ее не придется переделывать. Если работа вашей подпрограммы занимает только 1% общего времени выполнения, то, затратив сколько угодно времени на оптимизацию ее алгоритма, вы не добьетесь улучшения системных характеристик более чем на 1%. Такой выигрыш вряд ли стоит того, чтобы тратить время на оптимизацию. Со всеми остальными «программистским наворотами» дело обычно обстоит так же.
Неадекватное понимание целей конкретного проекта может привести к проблемам. Большинству опытных программистов свойственно стремление решать свою задачу не просто хорошо, а как можно лучше. Доводя свою программу до совершенства, программист способен затратить гораздо больше времени, чем реально требуется на задачу. Это стремление всегда вступает в конфликт с коммерческой стороной профессионального программирования, как способа получения прибыли. С точки зрения заказчика, качественная программа это та, которая удовлетворяет заявленным требованиям. Не более того.
Второе условие эффективной работы программиста — умение делать порученную работу. Как правило, начинающие программисты мало что умеют. Их главный метод программирования — копирование чужих образцов (Copy/Paste).
Это естественный путь обучения ремеслу. Вспомним художников, которые учатся, копируя полотна великих мастеров. Важно, чтобы образцы для подражания были достойными. Поэтому целесообразно поручать задачу паре программистов, в которой один из них выступает наставником, а другой подмастерьем, перенимающим опыт.
У меня нет личного опыта парного программирования, которое рекомендует xProgramming, когда одну программу пишут по очереди. Но есть накопленная с годами уверенность, что ревизия кода более опытным коллегой на предмет поиска «изобретения велосипеда» просто необходима. Кстати «изобретение велосипеда» любимое занятие не только среди начинающих, но и среди уже достаточно опытных программистов, у которых всегда возникает потребность переписать все по-своему. Этому, как правило, есть две причины. Первая — недооценка сложности поставленной задачи. Вторая — недостаток времени для изучения достижений и возможностей новых технологий, используемых в проекте. Дополнительно, парная ответственность за исходный код страхует ваш проект от негативных последствий неожиданного ухода одного из специалистов
Третье условие эффективной работы — программисту должна быть предоставлена возможность решить поставленную задачу. Здесь речь идет не о тривиальном наличии компьютера и инструментов разработки. И не о наличие отдельного кабинета, о котором пишет Де Марко. В творческой деятельности обязательным элементом ответственности является свобода выбора пути решения стоящей проблемы. Свобода не только необходимое условие творчества, но и важный мотивирующий фактор. Предоставьте членам проектной команды право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет. Чем чаще мы ошибаемся, тем быстрее учимся и быстрее добиваемся успеха. Ошибки — это просто часть культуры инновации.
Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи. Для профессиональных управленцев отсутствие жестких сроков может звучать как нонсенс, но в творческой деятельности это один из обязательных элементов эффективной работы.
Бессмысленно заставлять программистов работать больше, устраивать сверхурочные авралы и субботники. Работать больше, это совсем не значит — работать продуктивнее. Наоборот. Излишнее давление и суета приводят к непродуманным решениям и многочисленным последующим переделкам. «Хорошо управляемое предприятие — это спокойное место. Зато «фабрика, отличающаяся "кипучей" деятельностью и "трудовым героизмом" работников, который бросается в глаза любому посетителю, является на самом деле плохо управляемой». Это не я сказал, это говорит управленец «в законе» .
И наконец, четвертое, задача не будет решена за любое отведенное на нее время, если у программиста нет желания это сделать. Или сумейте мотивировать программиста на выполнение задания, или передайте его задачу другому участнику проекта. Иного пути нет. Часто бывает ситуация, что программист не знает и не умеет, например, если технология совершенно новая, но хочет. И этого стремления, как правило, бывает достаточно, чтобы освоить новую технологию и успешно решить поставленную задачу.
