Когда вы используете код рефакторинга?

Ответ 1

• В рамках первоначальной разработки (красный/зеленый/рефакторинг)
• Когда предложенный обозреватель кода
• Когда мы заметили конструктивную точку боли
• При внесении другого изменения, если рефакторинг оказывает незначительное влияние, то есть обычно не влияет на другие файлы.

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

Ответ 2

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

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

Ответ 3

Я нахожу, что рефакторинг при повторном коде (предположительно для добавления/расширения функциональности) более 3 месяцев после его написания.

Если мне потребуется более 2 минут, чтобы понять, что делает блок кода, я разберу его, чтобы сделать его более понятным (или просто добавить еще несколько комментариев).

Ответ 4

как только пройдут все тесты.

Ответ 5

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

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

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

Ответ 6

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

В противном случае я обычно не прикасаюсь к исполняемому коду, даже если он пахнет.

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

Рефакторинг при необходимости:

• когда вам нужно лучше понять код, над которым вы работаете (спаривание часто помогает здесь), примеры: переименование, извлечение метода и т.д.
• когда текущий проект не позволяет "чистого" изменения: на данный момент вы можете фактически спорить с вашим менеджером на основе значений (например, какая новая функция стоит для проекта).

Ответ 12

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

После DRY принципы яростно часто будут пуском для рефакторинга.

Ответ 16

Недостаточно часто, тем самым создавая технический долг.

Грустно, но так.

Делайте, как я говорю, а не как команда, над которой я работаю.