В общем я тут наверное расклеился, и не всегда есть время оценить полностью проект, продумать архитектуру, и постоянно натыкаюсь на свои же костыли. Они вполне себе безобидны, но мою перфекционистскую натуру раздражают.
Вот скажите, вы сразу пишете /идеальный/ код, или, когда проект уже на 95% готов, садитесь и рефакторите его?
Идеального кода не существует. А рефакторить на стадии 95% готовности проекта уже поздно. в tdd практикуют итерационный подход, у вас есть непрерывный цикл - пишем тест - реализуем логику - рефакторим. Если вы не пишите тестов, то всеравно этот подход имеет право на жизнь. Сколько писать кода между итерациями решать вам. Если становится тяжело рефакторить ибо объемы большие - стоит чаще это делать.
Ну мне тут просто один мой тимлид-джедай-магистр подсказывает, что рефакторить лучше, когда почти весь проект сделан (wat?), тогда, по ему мнению, лучше знаешь, как более рационально всё забабахать.
knitevision1: ну не совсем. Рефакторинг без причины признак дурачины. А если проект завершен на 95% то смысла тратить время и ловить регрессии не особо есть.
Если проект состоит из нескольких итераций, то просто закладывается время на рефакторинг перед каждой из них. Но и в процессе разработки минимально менять код тоже нужно.
Тут самое страшное это регрессии. Без покрытия кода тестами при каждом релизе придется прогонять фул тест вручную и на это будет уходить масса времени.
knitevision1: то есть как, вы конечно же должны по завершению проекта делать какую-то ретроспективу на будущее - что пошло не так, что можно было бы сделать лучше и т.д. Анализ решения нужно делать и это правильно. Но просто так "улучшать" уже полностью готовое решение тоже не хорошо, только если вы точно знаете что текущая реализация будет мешать в будущем. Хотя лучше уж тогда просто сделать себе пометку и при оценке нового функционала закладывать время на рефакторинг.
Хотя еще зависит от того что вы пишите. Если это ваш личный продукт - вам решать как поступать. А если это старый добрый аутсорс то лучше минимизировать риски регрессий и не трогать рабочий код без объективной необходимости. Если у вас на каждый релиз будет что-то ломаться заказчик будет грустным и в один прекрасный момент перестанет вам платить и уйдет от вас к кому другому.
Простой
