Рефакторинг: Когда вы знаете, что пора и когда вы это делаете? - PullRequest
5 голосов
/ 13 декабря 2008

Когда вы знаете, что пришло время реорганизовать / просмотреть какой-то фрагмент кода? А еще лучше, когда ты это делаешь?

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

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

Так когда вы знаете, что пора и когда вы это делаете? И больше всего, как вы включаете его в планирование проекта?

Ответы [ 16 ]

0 голосов
/ 13 декабря 2008

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

0 голосов
/ 13 декабря 2008
  1. Когда я готовлюсь к функциональным изменениям в коде (функция, исправление ошибок, производительность и т. Д.), Я сначала задаю себе вопрос, как бы выглядело, если бы код был идеально структурирован для этого изменения.

  2. Затем я выполняю рефакторинг в этом направлении

  3. Теперь я внесу функциональное изменение.

  4. Наконец, я снова рефакторинг, чтобы убрать уродство, вызванное моим изменением.

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

0 голосов
/ 13 декабря 2008

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

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

0 голосов
/ 13 декабря 2008

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

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

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

0 голосов
/ 13 декабря 2008

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

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

0 голосов
/ 13 декабря 2008

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

...