Покрытие кода выделяет неиспользуемые методы - что мне делать?

Мне было поручено увеличить охват кода существующего проекта Java.

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

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

Какой будет лучший подход? Напишите для них юнит-тесты или вопрос, почему они там?

1. Удалять.
2. Commit.
3. Забудьте.

Обоснование:

1. Мертвый код мертв. По своему описанию это не имеет смысла. Возможно, в какой-то момент у него была цель, но этого уже нет, и поэтому код должен исчезнуть.
2. Контроль версий гарантирует, что в (по моему опыту) редком уникальном событии, которое кто-то позже приходит в поисках этого кода, его можно извлечь.
3. В качестве побочного эффекта вы мгновенно улучшаете покрытие кода, ничего не делая (если только не проверен мертвый код, что редко бывает).

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

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

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

В этом случае есть четыре возможности:

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

Сначала убедитесь, что ваш инструмент покрытия кода правильный.

У меня были ситуации, когда они не улавливали методы, вызываемые через ссылки на интерфейс, или если класс загружался где-то динамически.

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

Какой будет лучший подход? Напишите для них юнит-тесты или вопрос, почему они там?

Удаление кода это хорошая вещь.

Если вы не можете удалить код, вы, безусловно, можете пометить его как @Deprecated , документируя, на какой основной выпуск вы нацелены, чтобы удалить метод. Тогда вы можете удалить его «позже». В то же время будет ясно, что не следует добавлять новый код, который зависит от него.

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

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

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

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

Если ваша компания использует моно-репо , то удаление имеет меньший риск, чем в случае мульти-репо.

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

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

вопрос почему они там?

Время, потраченное на захват знаний, не обязательно тратится впустую. Мне известно, что удаление выполнялось в два этапа: сначала добавив и зафиксировав комментарий, объясняющий то, что мы узнали о коде, а затем удалив код (и комментарий).

Вы также можете использовать что-то похожее на записи архитектурных решений как способ захвата знаний с исходным кодом.

Инструмент покрытия кода не всезнающий, всевидящий. То, что ваш инструмент утверждает, что метод не вызывается, не означает, что он не вызывается . Существует отражение, и в зависимости от языка могут быть другие способы вызова метода. В C или C ++ могут быть макросы, которые создают имена функций или методов, и инструмент может не видеть вызов. Итак, первым шагом будет: Выполните текстовый поиск имени метода и связанных имен. Спросите опытных коллег. Вы можете найти это на самом деле используется.

Если вы не уверены, ставьте assert () в начале каждого «неиспользуемого» метода. Может быть, это называется. Или заявление о регистрации.

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

Возможно, код на самом деле полезен, часть 2. Код может выполнять очень дорогие тесты во время выполнения, которые могли бы обнаружить, что что-то идет не так. Код включается только в том случае, если что-то идет не так. Возможно, вы удаляете ценный инструмент отладки.

Интересно, что худший из возможных советов «Удалить. Фиксация. Забудь». это самый высокий рейтинг. (Обзоры кода? Вы не делаете обзоры кода? Что на самом деле вы делаете программирование, если вы не делаете обзоры кода?)

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

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

Мы регистрируемся на выделенном #unreachable-codeрезервном канале с уникальным идентификатором для каждого кандидата на удаление, и это оказалось довольно эффективным.