maytonЯ не говорил что рефакторят каждый день. Собственно сама задача рефакторинга
не имеет оценочного business-value. Собственно это минимизация рисков усложнения
при будущих CR.У вашего же Фалера написано когда нужно делать рефакторинг:
- когда не производится ревью коданепонятно как работает код
- когда нет архитетекторавнезапно возникают новые требования

maytonБудет вам... Он такой-же наш как и ваш...Вы можете написать когда нужно делать рефакторинг? А то мнения расходятся - вот второй сумасшедший Мартин пишет что рефакторингом нужно заниматься после каждого мочеиспускания (перевод неточный - старался смысл наиболее полно передать):Uncle Bob MartinThe word “refactoring” should never appear in a schedule. Refactoring is not a story or a backlog item. Refactoring is not a scheduled task. Refactoring is immediate and continuous. It’s like washing your hands in the bathroom. You always do it.И эту концепцию я вообще понять не могу: сидишь себе спокойно, пилишь фичурефакторишь, тут тебе в багтрекинт прилетает мега-срочная бага с одной из семи сред, со всякими стректрейсами, шагами воспроизведения и пр. - начинаешь смотреть в код, а в коде нихрена таких классов и методов нет - уже все отрефакторили

mayton, вы же на вопрос не ответили... давайте в вашем сообщении заменим слово "рефакторинг" фразой "вызвать шлюх", при этом связность текста не потеряется:maytonВ нашей команде вопрос о вызове шлюх может поставить любой разработчик.
Решаем и оцениваем командой. Обычно 99% мы заинтересованы в быстрой
поддержке кода поэтому в большинстве случаев все согласны с необходимостью.

Резкого неприятия или каких-то особо резких выступлений "против" не было.
Заводить или не заводить стори в бэклоге - решаем ситуативно. Обычно (99%)
вызов шлюх связан с текущей разработкой и проводится и тестируется
в скоупе задач спринта.

Положительный поинт - перед вызовом шлюх обычно смотрим code-coverage.
И если где-то есть непокрытие - фиксим. И только после этого вызываем.

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

Вот вы пишите про некий техдолг, который имеет свойство накапливаться и т.п., накапливается он только по двум причинам:
- кто-то лажает с code review - никакие рефакторинги здесь уже не помогут
- поджимают сроки - здесь вообще нет никаких препятствий прямо с code review завести CR на переделку фичи - оно сразу будет учтено где нужно

mayton,

чет жесть какая-то, вот вы утверждаете: "Рефакторинг - это просто правила хорошего тона в обществе. Это как не плевать на пол и не кидать бумажки", если рефакторинг такой полезный, то должны существовать какие-то критерии, определяющие когда его нужно делать, и способ оценки этой "полезности", про полезность я вас пока не спрашиваю: вы пишите, что с "продажей" рефакторинга заказчику возникают проблемы, а в таком случае, вы это мне точно не сможете продать, я пока спрашиваю о том, когда нужно делать рефакторинг (мнение же идолов разнятся: один пишет что нужно 10 раз в день делать, второй, что когда в проекте появляются некие "непреодолимые препятствия" - при этом предпосылки обоих мне совершенно понятны: книжек из одной страницы с единственной фразой "дебилы, наймите себе наконец-то архитектора и делайте ревью кода" много не продашь, поэтому приходится лить воду как только можно, ну а потом, естественно, продавать консалтинг дятлам, которые не в состоянии прочесть и понять прочитанное). Причем что самое удивительное, что куда более разумную и логичную идею "лучше не пропускать плохой код, чем потом рефакторить", которая в буквальном смысле соответствует вашему "это как не плевать на пол и не кидать бумажки", вы полностью отвергаете - где здесь логика?

Вот давайте вернемся к злополучному коду от маэстро BDD:



как по мне, так здесь очевидно, что такой код пропускать нельзя, для этого даже не нужно смотреть что он на самом деле делает - у него просто отвратительная конвенция наименования, т.е. взгляд ревьювера здесь должен цепляться не за "Assert.isTrue(set.containsAll(set1))", а за "set" и "set1" - просто пишем что код плохой, без всяких объяснений и идем дальше - для ревьювера это дело пары секунд, даже вникать не нужно в то что происходит в коде, как только автор кода заменит эти "set" и "set1" на "returned" и "expected", то сразу же будет видна ошибка "Assert.isTrue(returned.containsAll(expected))" - это еще пара секунд без прикладывания каких-либо умственных усилий. Теперь давайте представим, что ваши замечания к коду несут рекомендательный характер, что это значит? Означает это следующее: после того как вы спалили плохую конвенцию "set" и "set1", вам нужно двигаться дальше и пытаться понять что именно там происходит, в конкретном примере все довольно просто (хотя некоторые индивидуумы уже здесь не справляются), однако если код более-менее сложный, то вам придется как минимум выписать его себе и уже смотреть в IDE (погуглите почему, к примеру, Торвальдс постоянно обоссывает плюсы - основной пойт в том, что невозможно понять изменения основываясь на одном лишь дифе файлов, та же беда с жавой) - получается так, что там где можно было просто взять и потратить на ревью кода 10 секунд, мы будем тратить полчаса, а потом еще и рефакторить - это глупость.

Дополнительный вопрос : сколько стоит поправить плохую naming convention, с учетом что у нас бывает рефлексия, сериализация, БД, внешние системы и т.д.?

Едем дальше, вот мое видение на то, как тот же тест должен выглядеть:



Я искренне надеюсь, что не нужно объяснять почему один код лучше другого, то вот же проблема: если у вас "рефакторинг" продуктового кода вызывает некие проблемы с обоснованием необходимости, то что тогда будет происходить с кодом тестов? Я так понимаю что для поклонников [TB]DD такое вообще невообразимо: как же так, мы тестовые сценарии ставим во главу разработки, а они оказывается полная хрень.

Эпикриз: техдолг возникает не сам по себе, а потому что это кто-то допускает.

Озверин,

я несколько не понимаю какую мысль вы хотите донести, ну, т.е. я понимаю, что бывают сроки и пр., но как это сказывается на разработчиках? Срыв сроков - это в первую очередь вина руководителя проекта и выше по иерархии, но никак не разработчика: руководство бонусы получает, а разработчик сидит на фиксированной ставке, вот пусть руководство за сроки, техдолг и пр. отвечает. Зачем вы стартапы в пример приводите - вообще непонятно, абсолютное большинство стартапов состоит из долбоебовлюдей, задача которых состоит в освоении денег инвестора, чуть более чем полностью. Вы в скольких стартапах участвовали? одной руки хватит чтобы пересчитать?

Поймите простую вещь: то что пишут в книжках, оно априори рассчитано на текущую конъюнктуру - иначе книжку не продать, другими словами эти книжки рассчитаны на команды, в которых бОльшая часть разработчиков - люди, с несколько более смуглым оттенком кожи чем ваш, и в таких командах рубить говнокод на корню довольно плохая затея, потому что завтра вам попадется негр-трансвестит, который будет утверждать, что его код зарубили только из-за его мировоззрения (тесты-то все зеленые!), в следствие чего одни понятия (код изначально должен быть хорошим) заменяются другими (весь код плохой, поэтому нужно его постоянно рефакторить) - это неправильно, рекомендую вам купить любую такую книжку, потом сжечь, обоссать и выкинуть.