«Слишком совершенный код» или чем вреден перфекционизм

Как отличить здравое желание улучшить код от «помешательства» на совершенстве? Разберемся, когда и почему перфекционизм вредит разработке.

3 степени перфекционизма

Алексей Хворост, менеджер разработки СКБ Контур считает, что перфекционизм в той или иной степени присущ каждому программисту: «Я выделяю три степени перфекционизма:

• Отсутствие перфекционизма: готов делать так, как сказал заказчик. 
• Здоровый перфекционизм: понимаю, чего хочет заказчик, готов обсудить 5 вариантов реализации и найти компромисс.
• Гиперперфекционизм: есть строгое понимание того, как должна быть спроектирована система. Сложно найти компромисс с потребностями заказчика, не можешь написать ни строчки кода, которая бы приносила удовольствие. 

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

Случай отсутствия перфекционизма: с реализацией каждой новой фичи в коде появляются дыры, так как заказчик вряд ли расскажет или вспомнит все нюансы поведения системы, а программист реализует в точности то, чего хочет заказчик. Одновременно с реализацией фич растет сложность кодовой базы и технический долг, так как разработчик не обременяет себя организацией архитектуры. В итоге, при достаточно большом n, система попадает в состояние, когда разработчик реализует n+1 фичу за огромное время или просто не в состоянии ее реализовать.

Случай здорового перфекционизма: реализация фичи происходит в диалоге, программист задает уточняющие вопросы о крайних сценариях, чтобы не появилось дыр в системе, уточняет степень корреляции нового сценария с предыдущими. Это помогает спроектировать архитектуру, понять, как растет сложность системы, дает обратную связь о том, что сложно реализуемо в системе, а что просто. Параллельно с реализацией фич программист отводит время на организацию кодовой базы, которая облегчает его труд. Даже в этой ситуации появляется технический долг (но в предыдущем случае он растет скорее экспоненциально, а в этом случае — линейно), растет сложность системы и это может приводить к снижению скорости реализации новых фич, но, в целом, проект более устойчив к изменениям.

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

Разумеется, здоровый перфекционизм — оптимальный вариант. Разберемся подробнее, как определить болезненную увлеченность совершенством.

4 признака, что пора притормозить с чистотой кода

Вы игнорируете требования заказчика

Вы ставите свой спортивный интерес выше задач и целей проекта.

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

Конечно, если ваше стремление к совершенству во благо проекту, пускай даже в долгосрочной перспективе, то это стоит отстаивать:

«При должном уровне развития в командах проводятся регулярные встречи, на которых обсуждаются наиболее приемлемые варианты для реализации того или иного функционала. На таких встречах вполне можно отстоять свою перфекционисткую точку зрения, если она действительно принесет что-то полезное» — считает Александр Булкин, менеджер проекта kino.1tv.ru.

Вы оттачиваете малозначительные детали

«В попытке довести свое решение до совершенства перфекционист уделяет ему слишком много внимания, оттачивая уже несущественные детали. Действительно, какие-то вещи он узнает глубже, становится экспертом в решении отдельных задач. Но, в целом, такое качество тормозит и ход проекта, и профессиональное развитие самого программиста: то же время он мог потратить, к примеру, на изучение других технологий. Если человек залипает на одной задаче и при этом не производит какой-то существенной работы, а постоянно переименовывает переменные или переделывает структуру классов, это повод обратить на него внимание» — описывает типичную ситуацию Андрей Баканов, руководитель отдела разработки MS CRM ИТ-компании Navicon.

Действительно ли, вы работаете над оптимальным решением наиболее приоритетной задачи?

«Перфекционизм, в общем случае, это некорректная работа механизма расстановки приоритетов. Он вредит, когда человек готов на любую мелочь бросить сколь угодно большие ресурсы, не задаваясь вопросом целесообразности» — считает Михаил, разработчик в компании DDoS-GUARD. 

Вы преследуете абстрактные цели

«Любое желание улучшить код должно нести в себе четкое понимание, какие цели предполагается достичь в результате улучшения. Разработчику следует понимать, какую ценность получит бизнес от улучшения кода. Перфекционизм в работе программиста должен выражаться не в бесконечном „допиливании“ кода до некоего абстрактно идеального состояния или поиске мельчайших багов, а в непрерывном саморазвитии разработчика как профессионала, следствием которого станет более высокое качество создаваемого продукта по основным критериям, как то соответствие продукта поставленным задачам, оптимальной производительности, красоте архитектуры и программного кода» — говорит Денис Журавлев, ведущий разработчик интернет-сервиса «Помогатель.ру».

«Абстрактный перфекционизм в вакууме — это признак некомпетентности. Но обычно такого не бывает — все понимают ситуацию в проекте и соглашаются на обоснованные понятные решения» — заключает Игорь Зиновьев, CTO в компании Дисциплина.

Когда перфекционизим полезен

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

Скажем, если вы собираетесь отправлять в космос марсоход или работаете над кодом браузера, который использует сотни миллионов человек, перфекционизм во всем — это вполне здравый подход. В тоже время в стартапах ранней стадии, как правило, куда важнее то, как быстро будет реализован функционал продукта на минимально приемлемом уровне. То, насколько аккуратно он сделан, — это дело десятое. Если продукт не заработает, то все усилия все равно пропадут в никуда» — говорит Игорь Зиновьев.

В любом деле, главное найти золотую середину.

«Перфекционизм не лишний, если:

• он не влияет на срок выполнения задачи;
• он не мешает вам поставлять продукт заказчику в рабочем виде и сохраняет его ценность для бизнеса;
• ваша команда согласна с вами и считает, что данная оптимизация требуется в этот момент времени» — суммирует Дмитрий Григорьев, сооснователь и IT-директор Rubrain.

Перфекционизм в обучении: профессия «Веб-разработчик».