Рефакторинг: Когда вы знаете, что пора и когда вы это делаете?

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

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

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

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

13.12.2008 16:25:52
16 ОТВЕТОВ
РЕШЕНИЕ

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

Если вы наследуете код, то я склонен думать о том, что есть 2 возможных подхода к нему:

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

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

4
13.12.2008 16:52:52

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

6
13.12.2008 16:29:13

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

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

10
13.12.2008 18:40:44

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

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

2
13.12.2008 16:33:09

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

0
13.12.2008 16:33:35

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

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

0
13.12.2008 16:39:35

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

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

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

0
13.12.2008 16:43:47
Начните с написания тестов, а затем выполняйте рефакторинг небольшими шагами, всегда следя за тем, чтобы не нарушать текущую функциональность.
Eran Galperin 13.12.2008 16:58:11
Я согласен с Эраном. Также попробуйте прочитать Эффективная работа с устаревшим кодом, это огромная помощь для этих сценариев: amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/…
orip 14.12.2008 22:48:45

Я думаю, что правильный ответ: всегда ! Работая над новой функцией, если я вижу фрагмент кода, который я могу изменить, я просто делаю это. Поскольку я использую TDD, я не боюсь, что старая функциональность перестанет работать.

2
13.12.2008 16:45:56

Когда твой код пахнет

2
13.12.2008 16:53:24

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

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

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

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

  3. Я сейчас делаю функциональные изменения.

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

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

0
13.12.2008 17:14:39

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

0
13.12.2008 17:58:53

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

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

0
13.12.2008 18:01:18

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

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

Тем не менее, я бы добавил свой голос всем остальным, кто говорит, чтобы тестирование обернулось вокруг кода. Постарайтесь, по крайней мере, охватить разумный набор «нормальных» случаев и внедрить некоторую автоматизацию (есть структуры, доступные практически для каждого языка), чтобы легко и быстро запускать тесты после каждого небольшого изменения. Хотелось бы, чтобы я знал / знал о тестировании фреймворков, когда впервые начал свою деятельность по очистке кода ...

0
13.12.2008 18:03:58

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

Вы завершили рефакторинг, когда достигли определенного целевого уровня нормализации . Если это просто общая очистка: 1,2 или 3 достаточно хорошо. Если вы расширяете код, то 4 или 5 лучше. Если вы действительно пытаетесь использовать существующую работу в течение длительного периода, тогда 6 - это путь.

Павел.

0
13.12.2008 18:09:47

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

Вы сказали, что код уже сломан. У вас может возникнуть соблазн пойти с тем, чтобы изначально сделать как можно меньше небольших изменений, чтобы заставить его «работать». Проблема в том, что без теста, как вы можете сказать, что это действительно "работает"?

Удачи тебе!

0
13.12.2008 18:19:26