У каждого программиста с накоплением опыта возникает некое обостренное чувство прекрасного. Думаю, это ощущение многим знакомо. Со временем формируется «вкус» к содержимому программы или её архитектуре. Возникает понимание того, что это должно быть сделано именно так, а не иначе, что хорошо, а что плохо. Появляются даже профессиональные капризы (Ненавижу, когда скобку переносят на следующую строку!)
Между прочим, какие фразы мы употребляем на работе?
Вообще, как метко подмечено, программисты — они как дети. То есть принимаемые ими решения зачастую основаны на эмоциях и вкусовых пристрастиях. Некоторые вообще считают, что так и должно быть, что профессиональное назначение программиста — это чистое, незамутненное творчество, рождение прекрасного, парение, так сказать, интеллекта над низменными инстинктами. Таких людей очень часто окружают ренегаты, дегенераты, бюрократы, мешающие творческому процессу.
Наверное, должно что-то произойти в голове, чтобы программист вырос из этого инфантильного состояния и у него человека развилось какое-то понимание проблемы. Я хочу отметить несколько основных моментов, которые я называю «прагматичными». Именно так работает множество менеджеров проектов по всему миру. В скобках замечу, что речь идет а) — о проектах от среднего до большого размера б) — о работе в команде (проекты, которые пишутся одиночками, мало показательны в этом плане).
Итак, вы менеджер проекта, технический руководитель, архитектор или team lead. К вам приходит программист, замученный исправлением багов, и предлагает новую супер-технологию, или «все переписать», или новый язык программирования (друзья сказали, что на PHP все это можно написать в три раза быстрее!). Как принимать решение?
Идеальных (с точки зрения архитектора) программных систем, которые работают и развиваются, не существует. Я бы даже сказал жестче: приведение системы к полностью идеальному виду, как правило, является для системы смертельным. Либо у владельцев системы очень много денег и программисты скучают — действительно, до кризиса такие явления встречались.
Если кто-то из моих коллег начинает яростно выражать желание что-либо усовершенствовать, «сделать красиво», начать жизнь с чистого листа, я для начала предлагаю этому человеку написать тесты для существующего функционала. Очень часто после этого все эмоции стремительно тухнут. Кстати, предлагаю я это сделать не по злобе, а на основании методики оценки сложности рефакторинга, описанной здесь.
Ничего плохого в желании все переписать нету. Действительно, в жизни часто встречается мусорный код, изуродованный многочисленными hotfix-ами и подпорками. Действительно, рефакторинг является частью жизненного цикла современного ПО. Однако суетиться в этом вопросе не надо. Серьезно охладить горячую голову программиста могут такие, скажем, вопросы:
Как видим, все довольно рационально. Фактически, мы руководствуемся некоей бизнес-арифметикой, где все числа взвешены с точки зрения реально приносимой пользы. Можно даже придумать «калькулятор решений», который будет приводить все pros and cons в цифровой вид :)
Знавал я ИТ-директора, который в свободное от работы время писал мелкие сетевые сервисы на Java. Просто так, для удовольствия.
Так что же, чем дальше, тем меньше простора для творчества? Не совсем так. Если проект/система развивается, то понадобятся и новые, свежие идеи, и современные «top-notch»-технологии. Однако без желания сопровождать и бесконечно ковырять существующий код никому эти идеи не нужны.
Между прочим, какие фразы мы употребляем на работе?
- Очень плохой код, надо убить разработчика и все переписать.
- Проще все переделать, чем починить этот баг!
- Консерваторы! Надо использовать mega-library версии 2.0, а не давно устаревшую версию 1.6.2.52.
Вообще, как метко подмечено, программисты — они как дети. То есть принимаемые ими решения зачастую основаны на эмоциях и вкусовых пристрастиях. Некоторые вообще считают, что так и должно быть, что профессиональное назначение программиста — это чистое, незамутненное творчество, рождение прекрасного, парение, так сказать, интеллекта над низменными инстинктами. Таких людей очень часто окружают ренегаты, дегенераты, бюрократы, мешающие творческому процессу.
Наверное, должно что-то произойти в голове, чтобы программист вырос из этого инфантильного состояния и у него человека развилось какое-то понимание проблемы. Я хочу отметить несколько основных моментов, которые я называю «прагматичными». Именно так работает множество менеджеров проектов по всему миру. В скобках замечу, что речь идет а) — о проектах от среднего до большого размера б) — о работе в команде (проекты, которые пишутся одиночками, мало показательны в этом плане).
Итак, вы менеджер проекта, технический руководитель, архитектор или team lead. К вам приходит программист, замученный исправлением багов, и предлагает новую супер-технологию, или «все переписать», или новый язык программирования (друзья сказали, что на PHP все это можно написать в три раза быстрее!). Как принимать решение?
Идеал недостижим
Идеальных (с точки зрения архитектора) программных систем, которые работают и развиваются, не существует. Я бы даже сказал жестче: приведение системы к полностью идеальному виду, как правило, является для системы смертельным. Либо у владельцев системы очень много денег и программисты скучают — действительно, до кризиса такие явления встречались.
Если кто-то из моих коллег начинает яростно выражать желание что-либо усовершенствовать, «сделать красиво», начать жизнь с чистого листа, я для начала предлагаю этому человеку написать тесты для существующего функционала. Очень часто после этого все эмоции стремительно тухнут. Кстати, предлагаю я это сделать не по злобе, а на основании методики оценки сложности рефакторинга, описанной здесь.
Надо все переписать
Ничего плохого в желании все переписать нету. Действительно, в жизни часто встречается мусорный код, изуродованный многочисленными hotfix-ами и подпорками. Действительно, рефакторинг является частью жизненного цикла современного ПО. Однако суетиться в этом вопросе не надо. Серьезно охладить горячую голову программиста могут такие, скажем, вопросы:
- Сколько займет переделка? При этом в уме я учитываю, что фанаты переписывания всегда склонны занижать трудоемкость. Кстати, переписыванием кода будет заниматься не только его инициатор, но и потенциально вся команда.
- Каковы риски? Управление рисками — вообще обширная и интересная тема (возможно, я напишу об этом отдельно). Упрощенно представим себе, что любой риск можно выразить процентом, на который возрастет трудоемкость работы, если данный риск все-таки возникнет. Допустим, к вам приходит Вася или Петя и взахлеб рассказывает, что производительность его серверного приложения можно серьезно улучшить, если добавить всего одну строчку кода. Одна незадача — эта строчка добавляется в код ядра Linux. Стоимость такой операции — минимальна, однако риски просто зашкаливают. А теперь попробуйте это объяснить Васе или Пете, которые считают вас перестраховщиком.
- Какое число новых функций (features) ожидается в будущем? Существуют участки проекта, в которых число потенциальных изменений минимально. Если они независимы от всего остального, почему бы не оставить их жить своей, безусловно нездоровой, но все-таки жизнью?
- Какой бизнес-приоритет имеет данная задача? Менеджер, как правило, постоянно держит эти приоритеты в голове. С точки зрения разработчика разбираться с какой-то там production-проблемой муторно и скучно, а писать новый код весело. Однако час, потраченный на исправление бага, может принести бизнесу $10K, а написание нового кода или новый крутой upgrade в итоге может не принести ничего, кроме морального удовлетворения программиста.
Как видим, все довольно рационально. Фактически, мы руководствуемся некоей бизнес-арифметикой, где все числа взвешены с точки зрения реально приносимой пользы. Можно даже придумать «калькулятор решений», который будет приводить все pros and cons в цифровой вид :)
Уйду в художники!
Знавал я ИТ-директора, который в свободное от работы время писал мелкие сетевые сервисы на Java. Просто так, для удовольствия.
Так что же, чем дальше, тем меньше простора для творчества? Не совсем так. Если проект/система развивается, то понадобятся и новые, свежие идеи, и современные «top-notch»-технологии. Однако без желания сопровождать и бесконечно ковырять существующий код никому эти идеи не нужны.