Вы делаете это, когда вы в коде делаете что-то еще?
Когда ваш менеджер одобряет это? (Кажется, этого не происходит)
Я думаю, что это зависит от влияния изменений. Если я изменю код и он ничего не влияет за пределы класса, для меня это малоэффективно.
Что это за изменения дизайна? Когда он воздействует на объекты X или X?
Мне просто интересно, как другие команды справляются с этим...
Если это влияет на общедоступный API, мне обычно нравится делать рефакторинг единым исходным кодом, который не меняет поведения (а затем создает новое поведение в другом коммите). Если это влияет и на другие проекты, то для этого должен быть консенсус, и я хотел бы получить разрешение на изменение своего кода, чтобы перейти в тот же рефакторинг.
Рефакторинг, когда вы уже находитесь в коде, иногда бывает проще, особенно если ваш менеджер не поддерживает инициативу, но если вы только измените небольшую часть, это нарушит согласованность с окружающими частями. В этих случаях лучше быть избирательным и, как вы предполагали, делать то, что малоэффективно. Также может быть полезно реорганизовать длинные команды select/switch в функции и задержка при повторном преобразовании внутреннего кода до тех пор, пока через некоторое время.
На предыдущей работе я был менеджером, поэтому я реорганизовал, когда захочу. На моей нынешней работе я аналитик, поэтому большая часть кода напрямую не связана с моей ответственностью. Когда я пишу код, я избегаю влияния на то, что я не пишу. У меня есть один проект, который полностью находится под моим контролем, и я реорганизую любое время, когда я узнаю лучший способ сделать что-то.
Я нахожу, что рефакторинг при повторном коде (предположительно для добавления/расширения функциональности) более 3 месяцев после его написания.
Если мне потребуется более 2 минут, чтобы понять, что делает блок кода, я разберу его, чтобы сделать его более понятным (или просто добавить еще несколько комментариев).
как только пройдут все тесты.
Я работаю в большой системе, поэтому я только меняю вещи, которые у меня есть. Легко иметь плохие побочные эффекты для изменений.
Я буду реорганизовывать разделы кода, которые работают плохо, не работают должным образом или нуждаются в новых функциях.
Я никогда не решаюсь исправить вещи, я никогда не буду. если он работает, и никто не просит изменений или жалуется на проблемы, продолжайте. жизнь слишком короткая, чтобы исправить все.
Я часто реорганизую свой код при изменении пользовательских требований или исправлении ошибок. Тогда у людей появится возможность просмотреть ваши изменения.
В противном случае я обычно не прикасаюсь к исполняемому коду, даже если он пахнет.
Мы обнаружили, что небольшие рефакторинги лучше всего делать, когда мы работали над небольшим количеством кода - делайте то, что требуется, желательно в паре.
Для больших вещей у нас был раздел "Технический долг" на стене - если вы что-то заметили и не нашли времени для его решения, или он решил обсудить некоторые вопросы, вы добавили бы его в стены, и они будут запланированы на будущие итерации (или когда наступит свободное время).
Мы реорганизуем так часто, как можем. Имея единичные тесты, чтобы гарантировать, что все работает до и после рефакторинга, действительно помогает.
Процессы обзора кода часто помогают в этом. Если я коснусь некоторого кода, он будет рассмотрен, рецензент спрашивает: "Почему вы это сделали?", Я говорю: "Мне пришлось из-за (вставить уродство здесь)". Это признак того, что код должен быть реорганизован сразу после завершения обзора.
Чтобы посмотреть на нашу компанию, мы решили, что наш выпуск приложений в основном посвящен оптимизации производительности, а не новой функциональности. Это было то, что мы чувствовали, было необходимо, а также было запрошено некоторыми клиентами. Поэтому мы потратили много времени на определение узких мест производительности в нашем приложении, а также на анализ кода и рефакторинг его, чтобы ускорить работу.
Итак, в нашем случае мы это сделали, потому что руководство одобрило нашу работу для этой новой версии, потому что мы показали им, насколько можно улучшить производительность.
Рефакторинг при необходимости:
Я всегда делаю небольшие рефакторинги в своем коде. Я знаю, что до тех пор, пока у меня есть свои модульные тесты, чтобы проверить, что все по-прежнему функционирует должным образом, я не вижу вреда в этом, когда я иду. Таким образом, вы не получаете этого неопределенного "необходимости рефакторинга" каждый раз, когда работаете над ним.
Теперь, если для этого требуется большой рефакторинг, лучше всего планировать это и отложить некоторое время.
Похоже, большинство других плакатов устойчивы к refacotring беспощадно. Конечно, это невозможно, если система, над которой вы работаете, не поддерживает это посредством обширных модульных тестов. Но в целом, если я вижу возможность сделать код более напряженным, не тратя больше нескольких минут или часов больше, я иду за ним. Если я не уверен, над чем я должен работать, я ищу что-то для рефакторинга.
Я реорганизую, когда исправляю ошибку или добавляю функцию, а процесс рефакторинга упрощает чтение кода и упрощает его поддержку.
После DRY принципы яростно часто будут пуском для рефакторинга.
Недостаточно часто, тем самым создавая технический долг.
Грустно, но так.
Делайте, как я говорю, а не как команда, над которой я работаю.