Как часто вы должны рефакторинг?

Question

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

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

Answer 1

Рефакторинг оппортунистически! Делайте это всякий раз, когда просто .

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

Сохранение рефакторинга для «обслуживания» - тавтология. Рефакторинг - это обслуживание.

Answer 2

Я выполняю рефакторинг каждый раз, когда читаю что угодно и могу сделать более читабельным . Не серьезная перестройка. Но если я подумаю про себя, "что это List содержит? О, Integer с!" тогда я изменю это на List<Integer>. Кроме того, я часто извлекаю методы в IDE, чтобы добавить хорошее имя в несколько строк кода.

Answer 3

Ответ всегда, но более конкретно:

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

Answer 4

Каждый раз, когда вы сталкиваетесь с необходимостью. По крайней мере, когда вы собираетесь изменить кусок кода, который требует рефакторинга.

Answer 5

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

Answer 9

Абсолютно, как только это кажется целесообразным. Если нет, боль накапливается.

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

Answer 10

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

Некоторые цитаты, подтверждающие его:

Дуглас Крокфорд, Старший Javascript Архитектор Yahoo:

рефакторинг каждый седьмой спринт.

Кен Томпсон (Unix Man):

Код сам по себе почти гниет и это буду переписан. Даже когда ничего изменился, по какой-то причине он гниет.

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

Редактировать: орфографическая ошибка