Покриття коду виділяє невикористані методи - що мені робити?

Мені доручено збільшити охоплення коду існуючого проекту Java.

Я помітив, що інструмент покриття коду ( EclEmma ) виділив деякі методи, які ніколи не викликаються з будь-якого місця.

Моя початкова реакція - не писати одиничні тести для цих методів, а виділити їх моєму лінійному менеджеру / команді і запитати, чому саме ці функції існують для початку.

Який був би найкращий підхід? Напишіть для них одиничні тести або запитайте, чому вони там?

1. Видалити.
2. Здійснити.
3. Забудь.

Обгрунтування:

1. Мертвий код мертвий. За своїм описом це не має жодної мети. Можливо, в один момент вона мала свою мету, але цього вже немає, і тому код повинен пропасти.
2. Контроль версій гарантує, що в (на мій досвід) рідкісній унікальній події, яку хтось пізніше піде, шукаючи цей код, його можна буде знайти.
3. Як побічний ефект, ви моментально покращуєте охоплення коду, не роблячи нічого (якщо тільки не перевіряється мертвий код, що рідко буває).

Застереження з коментарів: Оригінальна відповідь передбачала, що ви ретельно перевірили, що код, без сумніву, мертвий. ІДЕ є помилковими, і існує декілька способів, за якими насправді може бути названий код, який виглядає мертвим. Зверніться до експерта, якщо ви абсолютно не впевнені.

Всі інші відповіді ґрунтуються на припущенні, що розглядаються методи справді не використовуються. Однак у питанні не було визначено, чи цей проект є автономним чи певною бібліотекою.

Якщо проект, про який йде мова, є бібліотекою, то, здавалося б, невикористані методи можуть бути використані поза проектом, і видалення їх призведе до порушення цих інших проектів. Якщо бібліотека сама продається клієнтам або стає доступною для публіки, відстежити використання цих методів може бути навіть неможливо.

У цьому випадку є чотири можливості:

• Якщо методи приватні або пакетно-приватні, їх можна безпечно видалити.
• Якщо методи публічні, їх наявність може бути виправданою навіть без фактичного використання для повноти функції. Вони повинні протестуватися.
• Якщо методи є загальнодоступними та непотрібними, їх видалення буде суттєвою зміною, і якщо бібліотека дотримується семантичної версії , це дозволено лише в новій великій версії.
• Альтернативно, публічні методи також можна згодом припинити та видалити. Це дає деякий час споживачам API для переходу з застарілих функцій, перш ніж їх видалити в наступній великій версії.

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

У мене були ситуації, коли вони не використовували методи виклику через посилання на інтерфейс, або якщо клас кудись динамічно завантажується.

Оскільки Java є статично компільованим, видаляти методи слід досить безпечно. Видалення мертвого коду завжди добре. Існує певна ймовірність, що існує якась шалена система відображення, яка запускає їх під час виконання, тому спочатку зверніться до інших розробників, але в іншому випадку видаліть їх.

Який був би найкращий підхід? Напишіть для них одиничні тести або запитайте, чому вони там?

Видалення коду - це добре.

Якщо ви не можете видалити код, ви, безумовно, можете позначити його як @Deprecated , задокументувавши, який основний реліз ви націляєте на видалення методу. Потім ви можете видалити його "пізніше". Тим часом буде зрозуміло, що не слід додавати новий код, який залежить від нього.

Я б не рекомендував вкладати кошти у застарілі методи - тому немає нових тестових одиниць, щоб досягти мети покриття.

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

Я не можу говорити з EclEmma, ​​але з мого досвіду одна з речей, над якою потрібно бути обережною, - це рефлексія. Якщо, наприклад, ви використовуєте текстові файли конфігурації для вибору класів / методів доступу, використовуване / невикористане розрізнення може бути не очевидним (мене це спалювало в кілька разів).

Якщо ваш проект являє собою аркуш графіка залежності, то випадок депресії слабшає. Якщо ваш проект - бібліотека, то випадок депресації сильніший.

Якщо ваша компанія використовує моно-репо , то видалення є меншим ризиком, ніж у випадку мульти-репо.

Як зазначає l0b0 , якщо методи вже доступні в керуванні джерелами, відновлення їх після видалення є прямою вправою. Якщо ви дійсно переживаєте, чи не потрібно це робити, подумайте, як упорядкувати свої комісії, щоб ви могли відновити видалені зміни, якщо вони вам потрібні.

Якщо невизначеність досить висока, ви можете скористатися коментуванням коду , а не видалити його. Це додаткова робота в щасливому шляху (де видалений код ніколи не відновлюється), але це полегшує відновлення. Я здогадуюсь, що вам слід віддати перевагу прямому видаленню до тих пір, поки вас пару разів не спалить, що дасть вам певну думку про те, як оцінити "невизначеність" у цьому контексті.

питання, чому вони там?

Час, вкладений у захоплення краєзнавства, не обов'язково даремно. Мені було відомо, що видалення виконується в два етапи - спочатку додаючи та додаючи коментар, пояснюючи те, що ми дізналися про код, а потім видаляючи код (та коментар).

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

Інструмент покриття коду - це не всезнаюче, всевидиме. Просто тому, що ваш інструмент стверджує, що метод не викликається, це не означає, що він не викликається. Є рефлексія, і залежно від мови можуть існувати й інші способи викликати метод. У C або C ++ можуть бути макроси, що будують імена функції або методу, і інструмент може не бачити виклик. Отже, першим кроком було б: зробіть текстовий пошук назви методу та відповідних імен. Запитайте досвідчених колег. Ви можете виявити, що він фактично використовується.

Якщо ви не впевнені, на початку кожного "невикористаного" методу поставте assrt (). Можливо, це називається. Або протокол журналу.

Можливо, код насправді цінний. Це може бути новий код, над яким колега працює вже два тижні, і що він або вона збираються включити завтра. Сьогодні він не називається, тому що дзвінок до нього буде доданий завтра.

Можливо, код насправді є цінною частиною 2: Код, можливо, виконує дуже дорогі тести виконання, які зможуть знайти помилки. Код увімкнено лише у тому випадку, якщо справи дійсно йдуть не так. Ви можете видалити цінний інструмент налагодження.

Цікаво, що найгірша можлива порада "Видалити. Звернути. Забути". є найвищим рейтингом. (Огляди коду? Ви не робите огляди коду? Що на землі ви займаєтесь програмуванням, якщо не робите огляди коду?)

Залежно від середовища, в якому працює програмне забезпечення, ви можете увійти, якщо метод коли-небудь викликається. Якщо це не викликається протягом відповідного періоду часу, то метод можна буде безпечно усунути.

Це більш обережний підхід, ніж просто видалення методу, і може бути корисним, якщо ви працюєте в умовах, чутливих до несправностей.

Ми входимо в спеціалізований #unreachable-codeканал, що має слабість, з унікальним ідентифікатором для кожного кандидата на видалення, і він виявився досить ефективним.