Рефакторить нужно не всегда 
Последние несколько дней выдались довольно насыщенными - в четверг встречался с московскими коллегами-разработчиками, в пятницу отходил от встречи, затем ночной перелет до Красноярска, в субботу здоровый сон на весь день и вот в воскресенье, наконец, добрался до блога.
Меня часто обвиняют в чрезмерно идеальном подходе к разработке кода, типа в реальной жизни иногда нужно забить на качество и тупо решить задачу в лоб, в такой ситуации рефакторинг - это чистое мозгоклюйство. В четверг за кружечкой пива мы как раз обсудили эту черту моего характера. Для примера взяли проект, в процессе разработки которого сменилось три программиста. Так как условия разработки и квалификация разработчиков менялись в значительной степени, код получился разношерстным. Причем в одних местах исходники были просто идеально чистыми и красивыми, а в других от дублирования в глазах рябило.
Весь вопрос сводился к тому, как построить работу по сопровождению и развитию такого проекта? С одной стороны недостатки налицо - любой новый функционал внедряется с нечеловеческими усилиями и кучей багов. С другой стороны, один большой плюс - код работает и приносит заказчику прибыль. Переписывать проект - не выход. Это как раз тот случай, когда не сделав хорошо сразу потом переделать уже нельзя.
После жаркого обсуждения в неконструктивной манере (в основном речь шла о том, что сделать с руками предыдущих разработчиков), пришли к нескольким простым выводам:
- По возможности разрабатывать и сопровождать проект должны одни и те же люди;
- Не нужно рефакторить коммерческий код, если он работает;
- Если новый функционал требует изменение старого кода, то следует провести рефакторинг тех кусков, которые затронули новые изменения, но не более того.
Основной смысл в том, что если не трогать работающий код, то ничего страшного произойти не должно. Ну а если тронул, то следует потратить время и переделать все по-нормальному, чтобы исключить дальнейшее загнивание проекта.
подписаться на блог
Alex
Гость
>>Не нужно рефакторить коммерческий код, если он работает;
* Золотые слова
Так же стоит учесть, что код может относиться к проектам трех типов:
* отчуждаемому (тиражируемому, тому что будет работать в различном аппаратно-програмном окружении, поэтому он должен стабильно работать при переносе с одного окружение в другое)
* сервису (конкретному единичному сайту или SAAS-проекту - тому, что работает на каком-то конкретном железе и в конкретном окружении, но доступен множеству пользователей)
* единичному внедрению - код, который будет использоваться только на одном железе (в одном окружении) только одним или несколькими пользователем.
У каждого из этих проектом свои требования к расширяемости (развиваемости) и, соответственно, своя стоимость разработки
Евгений
Гость
Не о том ли я говорил раньше?
Я об этом: Если новый функционал требует изменение старого кода, то следует провести рефакторинг тех кусков, которые затронули новые изменения, но не более того.
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
Евгений, здесь я имею в виду ситуации когда тебе уже достается плохой код. Если речь идет о собственном коде, то рефакторить надо
Тормоз
Гость
А куда делись заметки про исключения? Хотел перечитать кое-что, и нету. Ай-я-яй.
Evgeny Sergeev
Веб-разработчик, автор блога codeart.ru
Заметаю следы. Не люблю быть неправым.
Тормоз
Гость
Какой ты, оказывается.
Leave a Reply