Про рефакторинг

[konstkaras]

Что меня смущает в порядке рефакторинга, предложенном Фаулером:1. Подход "сначала реализуй самым тупым способом, потом чисти код". Ну есть же принцип RefactorFirst. Рефакторинг для того и нужен, чтобы вносить изменения было проще - соответственно, вносить изменения надо тогда, когда система к этому готова. Можно, конечно, расчитывать на то, что код

Comments

[lodin]

Я так понимаю...

1. Часто оптимальный способ сделать задачу становится понятен уже после того, как она реализована "самым тупым способом". Да и попытки сделать идеально могут занять сколько угодно времени. Задача же не сделать вообще идеальный код, а сделать код, который выполняет задачу и с которым при этом не ужасно работать.

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

[lodin]

2. Двойная работа, конечно, зло, но она меньшее из зол в сравнении с "всё развалилось, узнали перед выкаткой".

[konstkaras]

Надёжность старой системы перенесётся на надёжность новой, с другой структурой и другой функиональностью? Благодаря тому, что в процессе разработки в какие-то моменты зачем-то бережно поддерживали старую функциональность и старую структуру? Попахивает какими-то ритуалами и магией. Благодаря самой малости шагов? Может быть.

[lodin]

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

И ещё, может быть, такой момент - если некоторое время работать в режиме "рефакторинг XOR функционал", прокачивается чутьё. У меня так было с TDD, во всяком случае - поначалу было тяжело писать тесты, а потом они стали получаться плюс-минус сами по себе.