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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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