Советы по работе с устаревшим кодом

Question

Мне нужен совет о том, как работать с устаревшим кодом.

Некоторое время назад мне было поручено добавить несколько отчетов в приложение для составления отчетов. написано в Struts 1, еще в 2005 году. Ничего страшного, но код довольно грязный. Не использовать формы Action, и в основном код - это одно огромное действие и множество операторов if-else внутри. Кроме того, никто здесь не имеет функциональных знаний по этому вопросу. Мы просто нашли это в нашем контракте.

Я совершенно недоволен этим и не знаю, как поступить. Это приложение невидимо: его используют немногие (но все очень важно), поэтому им все равно, кровоточат ли мои глаза при чтении кода, стандартов и т. Д.

Однако я чувствую, что технический долг должен быть оплачен. Как мне поступить? Продолжить движение по дороге if-else или попытаться выполнить это требование правильным образом, игнорируя остальную часть проекта? Запускаете огромный рефакторинг, рискуете моим сроком?

Answer 1

Устаревший код - большая проблема, и я уверен, что люди не согласятся!

Я бы сказал, что начинать большой рефакторинг может быть ошибкой.

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

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

И я быскажем, прежде чем вы сможете многократно переформулировать, вам понадобятся автоматизированные тесты, так что вы можете быть очень счастливы, что правильно соединили их!

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

Answer 2

Правило № 1: Если оно не сломано, не исправляйте его.

Правило № 2: Если есть сомнения, перечитайте правило № 1.

К сожалению, устаревший код можеточень редко можно описать как "это не сломано".Поэтому мы должны настроить существующий код, чтобы исправить недавно обнаруженную ошибку, настроить существующий код, чтобы изменить поведение, которое было ранее приемлемым, или настроить существующий код, чтобы добавить новые функциональные возможности.

Мой опыт научил меня, что любой рефакторингдолжно быть сделано «бесконечно малыми» небольшими приращениями.Если вы должны нарушить правило № 2, я предлагаю вам начать поиск с самого внутреннего вложенного цикла или структуры IF и расширяться наружу, пока не найдете чистую логическую точку разделения и не создадите новую функцию / метод / подпрограмму, содержащую толькокишки этого цикла или структуры.Это не сделает ничего более эффективным, но должно дать вам более четкое представление о базовой логике и структуре.Если у вас есть несколько новых, более мелких функций / методов / подпрограмм, вы можете реорганизовать и объединить их в нечто более управляемое.

Правило № 3: игнорируйте мой предыдущий абзац и перечитайте первые два правила.

Answer 3

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

Когда это будет сделано, скорее всего, вы лучше поймете, что делает этот код и как он работает.

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

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

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

Но не начинайте с рефакторинга

Answer 4

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

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

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

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