Как часто вы должны рефакторинг? - PullRequest
55 голосов
/ 26 сентября 2008

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

Если у вас есть мнение, защитите его.

Ответы [ 25 ]

1 голос
/ 27 сентября 2008

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

0 голосов
/ 26 сентября 2008

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

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

0 голосов
/ 26 сентября 2008

Есть много мнений по этой теме, некоторые связаны с определенной методологией или подходом к развитию. При использовании TDD рефакторинг на ранней стадии и, как вы говорите, часто является предпочтительным подходом.

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

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

0 голосов
/ 26 сентября 2008

Если это не сломано, не подвергайте его рефакторингу.

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

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

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

0 голосов
/ 26 сентября 2008

Я думаю, что в этом топ-100 посте на Wordpress может быть хороший совет. http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...