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

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

Итого, здесь ты написал, что рефакторинг у тебя есть улучшайзер, а менеджер снова "должен"

Рефакторинг это изменение структуры решения при гарантиях сохранения наблюдаемого поведения. Например, переименовываешь метод X в Y — рефакторинг. Обратное преобразование — снова рефакторинг. И так ты можешь заниматься целый день или даже месяц, вернуться к тому же X и всё равно это будет рефакторинг
business value это не свойство рефакторинга, как ты думаешь, а цель, ради которой он проводится. Применять как локально, так и глобально, как точечно, так и непрерывно. Точечный рефакторинг хорош, но глобального эффекта не даёт. Глобальный рефакторинг тоже хорош, но без непрерывного локального рефакторинга его просто не втащить — слишком много изменений.

А вот выделять рефакторинг в отдельную фазу проекта мягко говоря смысла не имеет, т.к. это превращается в судорожный улучшайзинг, а бОльшую часть времени люди будут работать с устаревшей структурой кода. Да и заказчик не склонен ждать даже несколько недель пока закаончится эта фаза.

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

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

Итого, здесь ты написал, что рефакторинг у тебя есть улучшайзер, а менеджер снова "должен"

Рефакторинг это изменение структуры решения при гарантиях сохранения наблюдаемого поведения. Например, переименовываешь метод X в Y — рефакторинг. Обратное преобразование — снова рефакторинг. И так ты можешь заниматься целый день или даже месяц, вернуться к тому же X и всё равно это будет рефакторинг
business value это не свойство рефакторинга, как ты думаешь, а цель, ради которой он проводится. Применять как локально, так и глобально, как точечно, так и непрерывно. Точечный рефакторинг хорош, но глобального эффекта не даёт. Глобальный рефакторинг тоже хорош, но без непрерывного локального рефакторинга его просто не втащить — слишком много изменений.
Например, есть задача — пофиксить баг. Здесь не надо думать про сейчас и потом, баланс и гармонию, инь и янь. У бага есть причины и есть конкретное место, где ошибка. Исправлять, как правило, нужно и то, и то. Если исправляется только сама ошибка, без воздействия на её причины, количество багов в среднем увеличивается.

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