Чи може хтось пояснити плюси видалення (або збереження) невикористаного коду?

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

Мої моменти щодо не видалення:

• Кодекс вже написаний, і зусилля витрачаються
• Код може бути протестований на синтетичному та реальному середовищі
• Якщо добре організовано (згруповано, окремий пакет, нещільно пов'язане тощо), це не заважає вам на загальний аналіз коду чи рефакторинг
• Код може бути використаний у майбутньому
• Після видалення автор може відчувати себе незручно

Чи може хтось пояснити плюси видалення (або збереження) невикористаного коду?

Ось кілька причин, чому невикористаний код слід видалити:

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

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

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

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

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

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

@suspectus зробив чудову роботу, представивши причини видалення коду; Я хотів би звернутися до ваших окремих куль для збереження коду.

• Кодекс вже написаний, і зусилля витрачаються

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

• Код може бути протестований на синтетичному та реальному середовищі

Вибачте, я не знаю, що ви маєте на увазі під цим.

• Якщо добре організовано (згруповано, окремий пакет, нещільно пов'язане тощо), це не заважає вам на загальний аналіз коду чи рефакторинг

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

• Код може бути використаний у майбутньому

У школі Agile ми говоримо YAGNI : Вам це не потрібно. Так, ви могли б , можливо , є використання для цього в майбутньому, але ми не можемо сьогодні досить про завтрашні потреб , щоб бути в змозі передбачити , що з якою - або надійності знаю. Думати інакше - це зарозумілість, що тяжіє до обману. Що ми можемо знати про завтра: ми хочемо, щоб нашу базу коду було легко змінювати, а невикористаний код відволікає цю характеристику.

• Після видалення автор може відчувати себе незручно

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

Хіба це не досить складно, щоб забрати якийсь код і з'ясувати наміри, але тепер ви повинні з'ясувати, які деталі не використовуються?

Кодекс вже написаний, і зусилля витрачаються

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

Код може бути протестований на синтетичному та реальному середовищі

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

Якщо добре організовано (згруповано, окремий пакет, нещільно пов'язане тощо), це не заважає вам на загальний аналіз коду чи рефакторинг

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

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

Ви вносите шум до введення інструментів і сподіваєтесь, що вони правильно впораються з ним.

Що робити, якщо ваш інструмент статичного аналізу обчислює співвідношення коментарів / коду? Ви просто зіпсували це з чимось, що було актуальним до вчорашнього дня (або кожного разу, коли прокоментували код).

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

Код може бути використаний у майбутньому

Якщо це так, ви знайдете його в СКМ вашої команди.

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

Після видалення автор може відчувати себе незручно

Так?

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

Це частина програми, що більшість написаних кодів остаточно буде відкинуто; Наприклад, Джоел Спольський якось сказав, що для його компанії приблизно 2% написаного коду бачать виробництво.

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

Редагувати: я бачив одну поважну причину залишати коментований код у джерелі, і це дуже специфічний випадок: коли код записується у дивному / неінтуїтивному вигляді і чистий спосіб його повторного запису не відповідає робота з дійсно тонкої причини. Це також слід застосовувати лише після повторної спроби виправити проблему та кожного разу, коли спроба повторно вводила той самий дефект. У такому випадку слід додати коментований інтуїтивний код як коментар та пояснити, чому він не працює (тому майбутні розробники не намагатимуться знову змінити те саме):

// note by <author>: the X parameter here should normally
// be a reference:
// void teleport(dinosaur& X);
// but that would require that we raise another dinosaur and
// kill it every twelve hours
// as such, the parameter is passed by value
void teleport(dinosaur X);

Мертвий код забруднює ваш код

Мертвий код знижує зрозумілість і читабельність.

Кращі коди завжди повторно використовуються, і якщо у вас є мертві коди, це зменшує використання

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

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

• Страх . Це змушує команду більше турбуватися і менше виробляти. Коли вводиться більше мертвих кодів, кількість страху збільшується експоненціально. "Ми не знаємо, чи використовується цей біт, тому ми не сміємо його видаляти чи торкатися."

• Підмітальні зміни . Якщо щось, що потрібно змінити скрізь у системі, існує і в мертвому коді, чи ви його змінюєте? Дуже важко дізнатися, чи він точно не використовується десь, тому це завжди ризик. І навіть якщо це нічого не зламає, чи зможе взагалі діяти мертвий код, якщо він буде повернений до використання після цієї зміни?

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

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

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

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

• Невикористаний код - це більший простір пошуку як для перегляду, так і для всього іншого, що зазвичай сканує ваш код. Наприклад, компілятор, IDE, знайти у файлі, налагодження, статичний аналіз, більше для огляду, включення файлів, вихід з VCS тощо. Це сповільнює ці процеси та додає значного шуму.
• Невикористаний код не завжди є мертвим кодом. Він може страчуватися за певних обставин. Це може не тільки запропонувати вектор для помилок та проблем з продуктивністю, але також може бути проблемою для безпеки. Щодо продуктивності, це може виражати себе несподіваними способами, такими як більші завантаження.
• Невикористаний код запускає невикористаний код. Якщо ви видалите виклик функції, а потім знайдете використання цієї функції, щоб побачити, чи вона все ще потрібна, ви можете побачити відповідність попередньому невикористаному коду і припустити, що ви можете його зберегти. Чим більше невикористаного коду, тим більше хмелів можна визначити, чи не використовується код.
• Невикористаний код все ще часто закінчується необхідністю збереження. Скажімо, A і B залежать від C. З них B не використовується. Ви змінюєте C, а потім B wont компілюєте, оскільки ви видалили член із структури в C, для якої потрібен B, тепер вам доведеться виправити B або активно видалити його з компіляції. Ви повинні були просто її зняти.

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

У відповідь на ваші пункти ...

• Кодекс вже написаний, і зусилля витрачаються

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

• Код може бути протестований на синтетичному та реальному середовищі

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

• Якщо добре організовано (згруповано, окремий пакет, нещільно пов'язане тощо), це не заважає вам на загальний аналіз коду чи рефакторинг

Ваш код все одно повинен бути таким, але це лише помірно пом’якшує проблему. Це найдивніший аргумент почути, що щось слід організувати ще нечисто. Це нормально намагатися тримати код модульним і зменшувати залежності, але ви також хочете багаторазового використання коду, і якщо всі ваші модулі є острівними шансами, то ви вже не БУДЕТЕ. Ви також можете виявити, що ви робите надмірну розв'язку, що не робить нічого, однак зменшує проблему невикористаного безладного коду.

• Код може бути використаний у майбутньому

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

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

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

• Після видалення автор може відчувати себе незручно

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

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

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

Це обговорення кілька років, але я просто натрапив на нього ...

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

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

Ви впевнені, що код не використовується?

Для перевірки компіляції коду недостатньо. У C ++, якщо ви видалите "невикористаний" неявно визначений метод, як-от operator=ви не збираєтеся отримати помилку компілятора, клас просто мовчки почне використовувати (потенційно неправильну) реалізацію за замовчуванням. У Java або C # код може використовуватися через відображення. В об'єктно-орієнтованих мовах успадкування може відігравати певну роль (базовий клас тепер можна називати). Майже на будь-якій мові, можливо, взяла на себе інша перевантажена функція.

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

Агресивно видаліть невикористаний код

Ви платите за підтримку коду:

• Виправлення зламаних складок (інженерний час). Нещодавно у нас був складний ланцюжок #includeзмін, який вводив нову перевантаження невикористаного коду, що призводило до розумного розміру головного болю для кожного інженера в команді з десятків розробників.
• У машинних ресурсах на тестах (якщо припустити, що у вас є самоперевірка безперервного складання). Моя команда нещодавно переглянула всі наші найповільніші тести, і багато з них були над інакше невикористаним кодом. Інженери, які виконують тести на місцях або в рамках безперервної інтеграції, чекають випробувань над невикористаним кодом.
• З точки зору читабельності (знову інженерний час). Файли заголовків представляють API. Якщо вони включають функції, які ніхто не бажає використовувати, але всі повинні читати, крива навчання вашого коду набагато складніше.
• У пошуку коду (знову інженерний час). Чи прибираєте ви будинок, жорсткий диск чи Google Диск? Чим більше ви шукаєте домен, тим важливіше його мати відповідний вміст, щоб уникнути помилкових позитивних результатів (або ви використовуєте більш складний пошук, як веб-пошукова система).

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