Чи потрібно видалити невстановлений код?

Я працюю над кодовою базою середнього розміру (100 К), це весь відносно недавній код (менше року) і має гарне покриття тестових одиниць.

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

Чи потрібно видалити цей код, якщо я впевнений, що він більше не потрібен?

Причини її видалення:

• Менше коду, менше помилок
• Менше коду легше засвоюється для інших
• Це все ще знаходиться під контролем джерела

Причини зберегти це:

• Може використовуватися в якості довідника
• Це може бути корисним колись
• Можливо, було написано, щоб "закруглювати" функціональність класу

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

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

Всі причини, щоб його зняти, стоять.

Причини зберегти це:

• Може використовуватися в якості довідника
• Це може бути корисним колись
• Можливо, було написано, щоб "закруглювати" функціональність класу

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

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

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

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

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

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

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

Примітка . Зрозуміло, ще більш чистим рішенням було б зробити окремий проект для бібліотеки та додати залежність між проектами.

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

Однак це дещо змінюється, коли ви пишете утиліту або API, призначені для загального споживання. Так само, як ви ніколи не можете очікувати, що кінцеві користувачі програмного забезпечення будуть взаємодіяти з програмним забезпеченням так, як ви задумали, ви ніколи не можете сподіватися, що споживачі вашого коду захочуть використовувати ваш код саме так, як ви вважаєте, що вони повинні. У таких випадках, поки ви можете виправдати існування методу, "це дійсний спосіб бажати взаємодії з моїм об'єктом", тоді він, ймовірно, повинен увійти, тому що навіть якщо вам це не знадобиться, шанси хороші. .

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

Що стосується бітів, які важко отримати в першу чергу, і, схоже, є більш воскреслими, я б тримав їх трохи більше "наживо", ніж просто в контролі джерел. Люди не знають / пам’ятають, що вони існують - кажучи, що «ви можете просто знайти це в контролі джерел», припускається, що ви знаєте / пам’ятаєте, що він є! У таких випадках розглядайте питання про депресію (із заявою про помилку ("false")) або коментування.

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

Для цікавих кадаверів кодів я використовую archiveгілку в своїх системах управління версіями.

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

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

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

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

Однією з вагомих причин зберегти невикористані методи є: їх можна використовувати в інших гілках / тегах!

Вивчіть усі активні гілки та теги, перш ніж видаляти їх.

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

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

Але будь-ласка, перш ніж його видаляти, переконайтесь, що він ніде не використовується. У Visual Studio є функція під назвою Find All References, яка здійснює пошук усього рішення та знаходить будь-яку посилання на поточну змінну, метод, властивість, клас, інтерфейс тощо. Я завжди переконуюсь, що ніяких посилань немає, перш ніж видаляти частину мого коду.

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

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

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

Ніщо не забирає менше часу, ніж відсутність коду.

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

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

Якщо нічого, ніхто не втратить час на це.

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

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

Довгі коментарі до старого коду відволікають і ускладнюють навігацію.

З повагою

Дотримуйтесь цього простого алгоритму:

1. Це резервне копіювання в СКМ? Якщо так, перейдіть до 3.
2. Налаштуйте СКМ.
3. Викиньте речі .

Усі ваші бали на користь видалення дійсні.

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

Це називається "мертвим кодом" з причини. Нехай вона помре і спочивай у спокої.

Він буде залишатися в контролі джерел; він не повинен залишатися в активній базі коду.

Єдиний виняток - якщо код завершує розробку, і поки ви не використовуєте код, ви плануєте в кінцевому підсумку зробити цей код загальнодоступним, а інші можуть захотіти цієї основної функціональності. Потім просто спроектуйте тести, щоб переконатися, що ці частини коду працюють, що імітують те, як ви пропонуєте іншим, можуть використовувати ці частини коду. Однак якщо ви навіть розглядаєте можливість видалення коду і не можете створити вагомий привід зберегти його, він повинен піти. Невикористаний код робить більше роботи для всіх (важче читати код; код може бути порушений; більше роботи з обслуговування; тощо)

На мій досвід, видалення невикористаного коду теж може призвести до виникнення помилок. Ви можете забути, що у вас був цей код, і ви не будете шукати його в історії. Або ви навіть можете не знати, що хтось реалізував цей код, а потім видалив його пізніше. Знову ж, ви не будете шукати цього в історії ...

Без сумніву, невикористаний код - це неприємний запах.

ОНОВЛЕННЯ: Я щойно помітив, що Ед Стауб дав дуже схожу відповідь.