Здравствуйте, Disa,

Вам тут уже много что хорошего посоветовали.
Поделюсь своей методикой. При работе над большим change request я сперва все делаю так, чтобы работало, а потом, уже имея возможность взглянуть на все изменения свысока рефакторю свой код и, иногда, код, который непосредственно задействован в change request. Тем самым нагрузка по рефакторингу плавно распыляется по всему времени жизни проекта и начальство ничуть не против и при этом код неплохой и работать приятно.

Правда если приходится сталкиваться с проблемами дизайна, рефакторинг идет отдельной статьей и прежде чем к нему приступать менеджмент занимается расстановкой приоритетов.

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

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

E__>Сейчас стараюсь убирать косяки по мере их появления.

Есть же замечательный принцип: "Если приходится сделать что-нибудь второй раз — мы делаем это второй раз. Если что-то приходится делать третий раз — мы делаем рефакторинг". По-моему, очень правильный подход...
Хотя все относительно :0)
Но в процессе "тихого написания кода" этот принцип приносит свои плоды...

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

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

K>>Заниматься рефакторингом надо в свободное от работы время. Если больше заняться нечем.... (читаем любую книжку по теме имеющую отношение к реальности).

SS>Можете назвать конкретные книжки, которые по теме и близки к реальности? Мне кажется, что таковых не много.

Их всего-то парочка:

http://www.ozon.ru/context/detail/id/1308678/

http://www.ozon.ru/context/detail/id/2909721/

Автор(ы): Джошуа Кериевски
Издательство: Вильямс
Цена: 847р.

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

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

D>Скажите это нормально когда архитектор говорит что его не интересует чистота кода и что начальник отдела с ним соглашается и так же говорит (сам начальник) что при разработке не следует занимать рефакторингом а заниматься им только при получении уже результата т.е. контретной версии продукта?
D>Я с ним с обоими сильно спорю, но доказать нечего не могу. Просто меня вообще не слушают.

D>При создании большой системы архитектор 4 часа порисовал различных табличек на доске и через 2 недели составил в Visio визуальные формы как он их хочет видеть. Скажите какое участие в разработке новой болшой системы должен принемать архитектор? Может всетаки я неправ.

D>Буду очень благодерен если вы опишете как у вас обстоят дела с подобными вещами.

Вообще, с такими делами обычно плохо обстоят дела.
В идеале, как он мне видится, никаких архитекторов быть вообще не должно: должен быть ведущий программист. Что касается чистоты кода, то уже давно исследования показывают, что код должен быть чистый на любой стадии разработки, исключая прототипирование, которое в конечный результат вообще не входит, только тогда можно говорить о качестве продукции.

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