Здравствуйте, Poopy Joe, Вы писали:

I>>Тем не менее, если у тебя рефакторинг может дать на выходе фичу, не совсем понятно, зачем этот подход называть рефакторингом.
PJ>Если разработка фичи идет лучше, если еще и отрефакторишь код, то как еще я это должен называть?

Разработка фичи действительно идет лучше с рефакторингом — именно это Фаулер и пишет.
Проблема в том, что у тебя слово "рефакторинг" включает в себя как возможный результат эту самую фичу
То есть, порочный круг.
Соответсвенно, раз у тебя фича может быть результатом рефакторинга, то 100% изменений могут дать какую нибудь подлянку. Где ждать проблему — не ясно.

Если рефакторинг делать по-Фаулеру, то очевидно, что безопасные изменения чередуются с произвольными. Именно это Фаулер и пишет.
Безопасные это только те, где есть максимальные гарантии, включая юнит-тесты и многое другое, а не выборочные(конкретный юзер видит или не видит).

Бенефит простой — безопасные изменения обладают определенными свойствами, в силу которых их можно
1 анализировать, хоть глазом, хоть инструментами
2 комбинировать
3 автоматизировать — не часы, а минуты

Соответственно, фича это:
80% рефакторинга
20% произвольных изменений
Отсюда ясно, что подлянки нужно ждать от этих 20% а не откуда угодно, как у тебя

На самом деле 80 к 20 можно свести и к 99 к 1, т.е. вместо 'перепишем руками и скопируем много раз' будет 'обработаем инструментом'. Логическая цепочка длинее, но из за автоматизации она всё равно выполняется за минуты.

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

Итого — даже если наличие похожего кода обосновано, его можно обрабатывать автоматическими средствами, которые ничего не ломают.

Здравствуйте, Poopy Joe, Вы писали:

I>>Тем не менее, если у тебя рефакторинг может дать на выходе фичу, не совсем понятно, зачем этот подход называть рефакторингом.
PJ>Если разработка фичи идет лучше, если еще и отрефакторишь код, то как еще я это должен называть?

Разработка фичи действительно идет лучше с рефакторингом — именно это Фаулер и пишет.
Проблема в том, что у тебя слово "рефакторинг" включает в себя как возможный результат эту самую фичу
То есть, порочный круг.
Соответсвенно, раз у тебя фича может быть результатом рефакторинга, то 100% изменений могут дать какую нибудь подлянку. Где ждать проблему — не ясно.

Если рефакторинг делать по-Фаулеру, то очевидно, что безопасные изменения чередуются с произвольными. Именно это Фаулер и пишет — надо чередовать рефакторинг с не-рефакторингом, но не смешивать всё вместе.
Безопасные это только те, где есть максимальные гарантии, включая юнит-тесты и многое другое, а не выборочные(конкретный юзер видит или не видит).

Рефакторинг — эспрессо, фича-оптимизации-итд — американо.
Эспрессо-американо-эспрессо-американо.
Если все смешать — будет американо А долны быть фазы.

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

Соответственно, фича это:
80% рефакторинга (эспрессо)
20% произвольных изменений (американо)
Отсюда ясно, что подлянки нужно ждать от этих 20% а не откуда угодно, как у тебя

На самом деле 80 к 20 можно свести и к 99 к 1, т.е. вместо 'перепишем руками и скопируем много раз' будет 'обработаем инструментом'. Логическая цепочка длинее, но из-за автоматизации она всё равно выполняется за минуты.

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

Итого — даже если наличие похожего кода обосновано, его можно обрабатывать автоматическими средствами, которые ничего не ломают.