Работаем с легаси-кодом

Никто не любит легаси-код

Даже у опытных разработчиков начинается дёргаться глаз когда они слышат это словосочетание. Но не всё так страшно если подходить с умом и правильными инструментами.

Удали всё лишнее

Чтобы не делать лишней работы, давай для начала удалим весь неиспользуемый код. В Intellij IDEA есть встроенные инструменты анализа, ими и воспользуемся. Кликай на нужной папке правой кнопкой -> Analyze -> Run inspection by name -> Unused declaration. Всё что там нашлось, обычно можно спокойно удалять. После первой волны репрессий, запускай анализ снова. После удаления кода, мог появится новый неиспользуемый код (который использовался только в том коде, который ты удалил). Поэтому повторяй процедуру до тех пор, пока список не опустеет или стабилизируется.

Удали ещё

После того как ты удалил явно не используемый код, наверняка остался фактически не используемый код. Обнаружить его помогут инстументы для анализа покрытия. Если есть такая возможность - собери покрытие с боевого приложения - это даст максимально точную картину. Если такой возможности нет - собери покрытие при прогоне end-to-end тестов. Ты же доверяешь своим тестам? ;)

Мануалов по настройке приложения для сбора покрытия предостаточно (я об этом тоже как-то писал Измерение покрытия java-бекенда*), поэтому я не буду сейчас останавливаться на технических деталях.

Нашёл, удалил? Возвращайся к предыдущему шагу. После удаления кода мог появиться новый явно не используемый код.

За последние два месяца, мы удалили таким образом ~30% кода в одном из компонентов.

Работаем с тем что осталось

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

Один из возможных подходов здесь - посмотреть на суммарное покрытие класса end-to-end и юнит-тестами. Такую метрику умеет показывать SonarQube. Если покрытие хорошее, класс можно менять относительно безопасно, постепенно увеличивая покрытие юнит-тестами. В ходе рефакторинга потребуются небольшие изменения в соседних классах и постепенно код будет становиться более тестируемым.

Другой подход, который используем мы - risk-based. Мы определили опасный код, как имеющий большую сложность и маленькое покрытие. На основе данных о сложности и покрытии из SonarQube, мы составили приоритезированный список классов. Потом стали их рефакторить и покрывать юнит-тестами.

Итого

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