Что вы считаете перед рефакторингом кода?

Question

У меня есть приложение, которое только что отправлено. С тех пор как я написал это, я узнал об amfphp и propel. И то, и другое было бы неплохо использовать в приложении, но я не могу сказать, что это потребуется на данном этапе.

Какие вещи вы рассматриваете перед рефакторингом кода?

Answer 1

Проведите модульные тесты для проверки кода после рефакторинга.

Answer 2

Требуется усилие по сравнению с полученной выгодой и где она в приоритетном порядке соответствует другой работе.

Answer 3

Должен ли я?

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

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

Answer 4

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

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

Answer 5

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

Answer 6

Я должен дать +1 Дрейцу. Единственная причина, по которой не стоит проводить рефакторинг, заключается в том, что у вас нет юнит-тестов. Но даже это не означает, что вы не должны рефакторинг. Я должен сказать, что мой modus operandus - это сначала функциональность кода, а затем всегда рефакторинг для решения проблем дизайна. Повторите тошноту.

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

Но будьте осторожны! Рефакторинг без надлежащих инструментов (и это будет зависеть от языка и IDE) - это все равно, что вбить винт: вы можете попасть туда, но это не будет эффективно (и у вас могут возникнуть проблемы).

Answer 7

Я нюхаю код. Если мне не нравится запах (другими словами, он не пахнет, как я), тогда я мочусь по всему, пока он мне не понравится.

Поскольку программным методам нужны классные имена, такие как Agile или Design Patterns, я называю это Canine Refactoring.

После переписывания кода я некоторое время использую его, съедая свою собачью еду.

Answer 8

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

В первоначальном проекте мы фактически записали все входящие данные за 14 дней и сохранили снимок prod db в начале и конце этих 14 дней, а затем мы смогли сравнить состояние базы данных, используя старый код и новый код Но модульные тесты наверняка уберут часть страха: -)

Answer 9

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