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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

Answer 7

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

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

Удачи тебе!

Answer 8

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

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

Paul.

Answer 9

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

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

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

Answer 10

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

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