// codeart.ru / Офтопик / Рефакторить нужно не всегда Форум

Рефакторить нужно не всегда rss подписка

Автор: Evgeniy Sergeev

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

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

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

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

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

  1. >>Не нужно рефакторить коммерческий код, если он работает;
    * Золотые слова :)

    Так же стоит учесть, что код может относиться к проектам трех типов:
    * отчуждаемому (тиражируемому, тому что будет работать в различном аппаратно-програмном окружении, поэтому он должен стабильно работать при переносе с одного окружение в другое)
    * сервису (конкретному единичному сайту или SAAS-проекту — тому, что работает на каком-то конкретном железе и в конкретном окружении, но доступен множеству пользователей)
    * единичному внедрению — код, который будет использоваться только на одном железе (в одном окружении) только одним или несколькими пользователем.

    У каждого из этих проектом свои требования к расширяемости (развиваемости) и, соответственно, своя стоимость разработки :)

  2. Не о том ли я говорил раньше? 😉
    Я об этом: Если новый функционал требует изменение старого кода, то следует провести рефакторинг тех кусков, которые затронули новые изменения, но не более того.

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

  4. А куда делись заметки про исключения? Хотел перечитать кое-что, и нету. Ай-я-яй.

  5. Заметаю следы. Не люблю быть неправым.

  6. Какой ты, оказывается.

Leave a Reply

« »