Есть такая дилемма: предпочесть сделать рефакторинг кода либо реализовать новый функционал? Этот вопрос актуален для программистов, ведущих программистов, руководителей проектов и даже, в очень редких случаях, для руководителей высшего звена.
В чем проблема-то, собственно? В конкурентной борьбе лучшие шансы выжить имеет производитель более функционального, более дешевого ПО. Так как в статье я взялся рассматривать только один аспект этого вопроса, то задумаемся над тем, что мешает нам реализовывать много нового хорошего функционала? Недостаток людей, плохо поставленный процесс разработки- это все, да, явные причины того, что реализация новых функций, необходимых пользователю, затягивается по срокам. Но я вспоминаю из своего опыта один очень показательный пример.
Мы делали большую систему автоматизации предприятия. Меня наняли на эту работу именно под разработку этой новой системы. Новый функционал мы "шлепали" легко, пользуясь готовыми библиотеками. Так, что в среднем новый модуль выпускался в течение двух недель.Через пару лет сроки реализации нового функционала стали затягиваться, а мы старались уже поменьше влезать в код, неохотно разбирали на реализацию задания. В чем причина таких перемен?
Стараясь быстрее пользователям предоставить новый функционал, мы совершенно не делали рефакторинг кода. Программисты все отличные, код писался правильный. Но, во временем, он становился все менее пригодным для использования его при реализации новых функций. Стало много времени уходить на отладку потому, что поправишь в одном месте код, а это приводит по совершенно умопомрачительным связям к другой ошибке в совершенно другом модуле. Исправляешь там- что-то вылазит в другом модуле. Вот и боялись лишний раз тронуть систему- неизвестно где, кому и каким боком вылезут твои вмешательства. История закончилась на том, что развитие большой, многофункциональной системы прекратили. Вот так, недооценка рефакторинга привела к остановке проекта.
Как это происходит, что коду требуется рефакторинг? Крайние случаи рассматривать не будем. Считаем, что код пишет среднестатистический программист. Исходя из задания он его пишет правильно, немного закладываясь на перспективу развития, но не увлекаясь излишне абстракциями. Со временем функционал программы растет, и вот, уже существующий код, написанным нашим среднестатистическим программистом, не может покрыть требования пользователя. Если в данной точке вместо рефакторинга предпочесть побыстрей сделать новую функцию для пользователя, то можно
- из приватной части класса наружу вытащить нужную переменную и напрямую работать с ней,
- в параметры вызова функции добавить новый параметр и задать ему значение по умолчанию,
- в класс добавить новую переменную, а потом, по ее значению, в структурах if либо case сделать необходимые ветвления.
Уф, уже этого достаточно, чтобы мэтра Фаулера в могилу свести. Он и так грубоват в своем стремлении все зарефакторить (из-за чего я не люблю его труды и никому читать не рекомендую). Итак, случилось ужасное, в правильном коде проделаны дырки. Теперь, поправив значение бывшей приватной переменной, мы легко и непринужденно получаем ошибку в другом методе класса, не рассчитанном на прямой доступ к данной переменной. Но, мы же трудностей не боимся, нам надо новую функцию пользователю предоставить? Смело накладываем заплатку и готово. Пользователь рад- ему все равно какой там внутри код, начальник рад- дело быстро сделано, деньги получены, новый "лексус" куплен и программисту хорошо- никто не торопит, можно и пивка попить. Велик соблазн и далее работать в такой же манере, по-быстрому реализуя новый функционал, и не уделяя времени рефакторингу.
К сожалению, результат будет печален. Как саду требуется регулярная прополка, как машине нужен периодический техосмотр, так и программному коду требуется рефакторинг. Вот мы и пришли к первоначальному вопросу: потратить время на рефакторинг или лучше быстрее реализовать пожелание пользователя? Если вы программист- ответ простой. Делайте, как скажет начальник. Скажет делать рефакторинг- делайте, скажет делать новый функционал- делаете новый функционал. Вы- реализатор, ваше дело- "копать от забора и до обеда".
Если вы ведущий программист, то всегда приоритетен рефакторинг. В вопросе о сроках реализации сразу называйте срок с учетом рефакторинга. Это сложно, надо уметь убеждать начальство, что надо делать именно так. Тактично и без обид, что начальство тупое и не понимает всю важность вашего плана.
А начальству я советов давать не буду- мой блог не для них, и они вряд ли читают его.
