Refactoring vs. rewriting

[dimrub]

А вот еще такой вопрос ко френдам-программистам. Допустим, вы отвечаете за какой-то, достаточно значительный кусок кода. До вас этим куском кода в течении многих лет занималось еще множество народу, с частью из которых вы даже не знакомы, а другие уж далече. Вам кажется, что код этот - наказание за все ваши грехи: он с одной стороны имеет очень сложный для понимания дизайн, с другой - в течении тех лет, что его поддерживали, в него внесли кучу изменений, которые идут поперек этого дизайна. Таким образом в нынешнем его виде вносить в него дальнейшие изменения (о которых все время просят заказчики) - чистая и незамутненная радость. В такой ситуации есть два возможных решения:

1. Либо потратить кучу времени и сил на реставрацию: понаписать тестов, сделать рефакторинг, вернуть код к жизни.
2. Либо выбросить все, и написать, с учетом имеющегося опыта, заново.

Очевидно, что начальство двумя руками за 1-й вариант: переписывание - это риск, начальство рисков не любит. Очевидно также, что будут ситуации, когда будет выбран первый вариант, а будут - когда второй. Чем бы вы руководствовались при решении о том, какой вариант выбрать?

Comments

[mopexod.livejournal.com]

Да это же как юбка или брюки:) Всегда trade-off: насколько все запущено versus сколько есть запасных денег и времени.

[saper.livejournal.com]

ну да, как-то так

[12diozihcs.livejournal.com]

Имхо в реальности разница между первым и вторым мало ощутима: рефакторинг мягко переходит в переписывание с начала.

[motya.livejournal.com]

Есть еще третий вариант - стать Великим Мастером Чистой и Незамутненной Радости. Уважение и джоб секьюрити гарантированы :)

[dimrub.livejournal.com]

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

[motya.livejournal.com]

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

[cmm.livejournal.com]

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

последнее время таких кадров навострились увольнять первыми.
и это правильно.

[alexcohn.livejournal.com]

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

Если серьезно, то вариант №1 - тоже риск, и немалый. Никто не сказал, что после реставрации старый дизайн вообще будет работать. Собственно, из взвешивания рисков первого и второго и следует исходить, выбирая свой путь.

Бывают ситуации, когда вариант №2, в котором новый фактически продукт приходит, по мере созревания, на место старого, оказывается менее рискованным: во все время его разработки, старая версия по крайней мере не становится хуже.

[photon.livejournal.com]

+1

Судя по условиям задачи речь идет о достаточно большом куске кода, иначе уже бы давно выкинули и переписали. Скорее всего первый этап варианта 1 - "понаписать тестов" - уже не тривиальная задача, т.к. часть требований к коду (была) известна лишь предыдущим и недосягаемым участникам торжества. Разбиение на модули с целью рефактоить по отдельности скорее всего будет встречено активным сопротивлением со стороны такого кода.
С другой стороны, если мое первое предположение не верно и есть четкое понимание, что же код должен делать - второй вариант скорее всего дешевле первого.

Bottom line: если условия задачи ясны - предпочтительней переписать.
Если нет - не трогать и поставить заплатку.

[ex 314truha (from livejournal.com)]

В каждом ночальнеге сосуществуют внутренний администратор и внутренний инженер; пропорции в этой смеси зачастую определят выбор между 1, 2 и ненаписаным вариантом 3 - оставить как есть, ибо покамест работает и бежит на сайтах у клиентов.

непросто.

[haiut.livejournal.com]

Эх, я сам ежедневно сталкиваюсь с такой дилеммой, поэтому попоробую по порядку.

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

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

Мой опыт подсказывает, что желание переписать все нахуй возникает абсолютно у всех, но по мере приобретения опыта конкретно с данным проблематичным кодом это желание нередко проходит. Плохо только, если это происходит посреди полного rewrite ;-).

Короче, я за первый вариант, но с элементами второго ;-)
Т.е. не переписывать все подряд, а обложить тестами имеющееся, рефакторить и оживить все возможное, и после этого переписывать по частям. Таким макаром можно за некоторое время переделать проблемный модуль почти полностью, но это будет сделано в несколько итераций, с четким пониманием risks & benefits. Небольшие куски легче переписывать, легче делать им нормальный дизайн, легче тестировать.

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

И пардон за слишком "начальственное" мышление ;)
--

А собственно на вопрос я и не ответил :)
Видимо, главный критерий - риск/пользa. Риск зависит от сложности проблематичного модуля, возможности точно определить его задачи/спек, возможности тестирования, release nature (major, minor, patch). Польза зависит от количества и качества проблем в данном модуле (number of bugs & their severity, performance problems, unable to enhance/add new features). Дальше по списку - что я могу себе позволить с имеющимися кадрами, т.е. хватит ли людей/времени на предложенные варианты. Вот так, вроде.

Re: непросто.

[meharher.livejournal.com]

ППКС.
Выбираешь наиболее запущенные и наиболее критические части и их переписываешь, по мере возможности сохраняя интерфейс и конвенции.

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

[beldmit.livejournal.com]

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

[mryam.livejournal.com]

1. Сколько времени займет первый вариант и сколько второй - vs сколько времени до выпуска след. версии.
2. Кто будет этим заниматься.
3. В зависимости от первых двух - то, что проще+безопаснее.
Тесты нужны в любом случае.
Можно поделить на модули, и с каждым - по обстоятельствам.