Как и как часто вы проводите рефакторинг своего кода?

Question

Мой вопрос смутно относится к этому . Тем не менее, это не касается методов или практик.

Я читаю Прагматичный программист , и он настоятельно рекомендует рефакторинг кода так часто, как вы можете. Тем не менее, это не вдаваться в подробности о том, как это сделать и как часто. Как вы, ребята, занимаетесь рефакторингом своего кода и как часто вы проводите рефакторинг?

Answer 1

Когда и где необходимо.

Нет смысла проводить рефакторинг как таковой, это инструмент, облегчающий дальнейшее развитие. Рефакторинг только тогда, когда вы получите от этого преимущество. Небольшая библиотека, которая никогда не будет развиваться и будет протестирована, является идеальным кандидатом для того, чтобы не проводить рефакторинг. Любое время, потраченное на рефакторинг, не окупится. Части вашей системы / программы, которые будут развиваться, нуждаются в обслуживании и трудны для чтения, являются очевидными кандидатами на рефакторинг.

Всегда думайте о рентабельности инвестиций (окупаемости инвестиций), если вы начнете рефакторинг всего, что, по вашему мнению, могло бы быть лучше, то завтра вы снова проведете рефакторинг, и, может быть, когда-нибудь у вас будет время, чтобы действительно выполнить какой-то реальный аванс. *

Answer 2

Это похоже на уборку дома, вы должны убирать каждый день и выполнять небольшие задачи, которые необходимо выполнить, чтобы содержать вещи в чистоте. Затем (раз в неделю или около того) вы берете несколько часов и хорошо убираете дом сверху донизу. Наконец (раз в год или около того) вы делаете хорошую весеннюю уборку, вывозите весь мусор и начинаете заново.

Рефакторинг - это поддержание чистой базы кода, и это постоянные задачи, которые никогда не завершаются.

Answer 3

Я выполняю рефакторинг, только когда у меня есть код, охватываемый тестовыми примерами.

Answer 4

Всякий раз, когда я вижу дублированный код.

Всякий раз, когда я вижу возможность для более простого алгоритма / эвристики.

Все меньше и меньше, чем ближе я к релизу:)

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

Я работаю в основном в .NET, и ReSharper отлично справляется с этой задачей, а также автоматизирует многие виды операций рефакторинга. Я думаю, что есть аналогичные инструменты для многих других языков.

Answer 5

Я ищу возможности рефакторинга всякий раз, когда добавляю новую функциональность или особенно при изменении существующей функциональности

Answer 6

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

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

Answer 7

Главное никогда не сообщать своему боссу / клиенту, что вы проводите рефакторинг. Всегда включайте рефакторинг в нормальный поток работы. Не стоит постоянно объяснять, почему стоит платить.

Answer 8

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

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

Answer 9

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

Если вы можете позволить себе работать таким образом, большие и «страшные» рефакторинги не нужны так часто, как если бы вы не делали регулярные незначительные очистки.

Конечно, когда изменяется масштаб проекта, часто требуется рефакторинг, независимо от формы кода, но чем реже код рефакторинга, тем проще и быстрее.

Answer 10

Существуют уровни и уровни рефакторинга.

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

Большие рефакторинги (вид, о котором может беспокоиться OP), я в основном отношусь к ним как к новой функции. Я постараюсь получить консенсус о том, насколько это важно, и составлю соответствующее расписание. Я не буду вносить такие изменения, если только соответствующий код не имеет высокой степени охвата модульных тестов. «Если это не проверено, то оно сломано» - одно из следствий закона Мерфи. Кроме того, если он уже сломан, я не стану усугублять ситуацию, если рефакторинг кода будет плохо освещен.

Я также не занимаюсь рефакторингом, чтобы код соответствовал некоторому шаблону или чтобы его было легче изменить в будущем. Когда наступит будущее, оно придет с некоторыми неудачными юнит-тестами, которые не будут выполнены, пока я не внесу изменения. Если таких тестов нет, я не могу сказать, что мои изменения что-то сломали, поэтому я не буду проводить рефакторинг.