Рекомендации по работе с устаревшим кодом

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

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

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Правило №2: При возникновении сомнений перечитайте правило № 1.

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

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