Refactoring vs. rewriting

[dimrub]

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

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

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

Comments

непросто.

[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, учесть график следующих версий, чтобы успеть стабилизировать систему до очередного релиза.