Victor Ronin's IT blog

Сегодня, немного углублюсь в технические особенности рефакторинга и их бизнес последствия.

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

Естественно, проект лучше не доводить до жуткого состояния, но тем не менее, множество проектов до него таки доходят и зачастую не в ваших силах было на это повлиять (например, когда проект вам достался в наследство).

Собственно, в чем проблема проектов с плохим кодом. Опустим моральную сторону, что над проектом плохим кодом неприятно работать, так как постоянно приходится все делать через одно место.

С бизнес точки зрения проблема состоит в том, что:

— существенно увеличивается время на внесение изменений и написание новой функциональности

— соотношение поддержка старого кода / инновации, очень сильно начинает крениться в сторону поддержки

— увеличивается время «въезжания» новых программистов в проект

То есть, если у вас код плохой, а у конкурентов хороший, то вам приходится тратить гораздо больше денег, для того, чтобы проводить инновации и поддерживать качество продукта.

Сначала, опишу три выхода из этой ситуации, а потом обсудим каждый их них:

— сделать кучу маленьких рефакторингов

— переписать все заново

— сделать большой рефакторинг

Начнем с малого рефакторинга. В любой момент, если вы видите, что можно по ходу работы потихоньку обновлять и улучшать код – то это и нужно сделать, так как остальные выходы гораздо хуже (более рискованные и съедают больше времени и увеличивают время до выхода следующей версии).

Бывают такие ситуации, когда малые рефакторинги — не выход. Например, если постепенное улучшение кода может занять 5 лет.

Переписывать заново нельзя никогда. Точнее переписать прототип на рабочий код можно (а зачастую и нужно), но вот переписывать работающий продукт – это самоубийство.

Плохой код состоит из нескольких частей

— плохая и непродуманная архитектура (написание проекта без продумывания архитектуры наперед)

— плохой код на уровне использования языка (обычно это код написанный слабыми или неопытными программистами)

— кучу заплаток поверх архитектуры

Переписывание заново лучше всего решает архитектурные проблемы. Плохой код на уровне языка оно решает, только если текущие программисты сильные чем те, которые писали предыдущую версию. А вот с заплатками обычно наблюдаются проблемы.

Чаще всего большинство функциональности заплаток упускаются при переписывании, так как обычно это куча мелких частных ситуаций, которые не внесены не в тесты, не в документацию. И получается, что код переписан, но он не выполняет всей функциональности или не работает во все usercases. Причем, это обнаруживается в самом конце переписывания (когда начинается полное тестирование). И опять поверх стройной новой архитектуру начинают копироваться или переписывать заплатки из предыдущего проекта. Обычно это очень затягивается, фактически убивая заново написанный продукт.

Теперь, перейдем к возможности большого рефакторинга, о которой собственно это статья. Большой рефакторинг – это ситуация, когда он проводится не параллельно с разработкой чего-то нового, а скорее в режиме когда проект замораживается для новой функциональности и пофикса и начинается рефакториться день и ночь.

Обычно такой рефакторинг позволяет существенно улучшить качество проекта в достаточно короткие сроки, без необходимости переписывать проект с нуля.

И тут кроется одна большая проблема, качество кода, достаточно сложно измеримая величина. Поэтому рефакторить проект можно до бесконечности полируя заново какие-то кусочки. Поэтому, еще до того, как начинается рефакторинг нужно определиться с несколькими вещами:

— что конкретно улучшается

— поставить жесткие временные рамки

— точно определить как будет измеряться достижения целей

Если не соблюсти эти три правила, то рефакторинг превращается в научное исследования уходящее в бесконечность или ремонт (кому какое сравнение ближе к душе).

Очень важно избежать двух тенденций.

Первая тенденция – это то, что во время рефакторинга находятся все новые плохие куски, которые тоже хочется/нужно улучшить. Как только цели определены, то нельзя их изменять. Вполне имеет смысл иметь список, того, что хочется улучшить. Однако новые улучшения можно делать маленькими рефакторингами, когда большой будет закончен.

Вторая тенденция – это сверх улучшение качества, при этом выход за временные рамки. Цель рефакторинга, не является добиться идеального качества, а является увеличшенить качество до определенного уровня. Поэтому нельзя переконцентрироваться на полировке какой-то части перерасходуя бюджет и время.

Но, повторюсь еще раз, нужно пытаться всеми силами избежать большого рефакторинга, если маленький остается возможным.

 P.S. Если вы подписываетесь на получение  писем, когда кто-то добавил комментарии на статью, то теперь есть возможности перейти сразу на нужный комментарий из письма, вместо того, чтобы заходить на статью и искать вручную этот комментарий.

This entry was posted on Пятница, Февраль 15th, 2008 at 3:22 пп and is filed under Разное. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.