Запобігати складанню застарілого коду після досягнення граничного терміну [закрито]

У моєму колективі ми чистили багато старих речей у великому монолітному проекті (цілі класи, методи тощо).

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

Я шукав в Інтернеті і не знайшов нічого, що має можливості, описані нижче:

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

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

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

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

Однак ви можете додати деякі спеціальні примітки до подібного коду

@Deprecated_after_2018_07_31

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

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

Це являло б особливість, відому як бомба за часом . НЕ СТВОРЮЙТЕ ЧАСИ ЧАСУ.

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

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

У C # ви використовуєте ObsoleteAttributeтакий спосіб:

• У версії 1 ви надсилаєте функцію. Метод, клас, що завгодно.
• У версії 2 ви доставляєте кращу функцію, призначену для заміни оригінальної функції. Ви ставите застарілий атрибут на функцію, встановлюєте її на "попередження" і даєте їй повідомлення, яке говорить "Ця функція застаріла. Використовуйте замість неї кращу функцію. У версії 3 цієї бібліотеки, яка буде випущена на таких і подібних дати, використання цієї функції буде помилкою. " Тепер користувачі цієї функції все ще можуть користуватися нею, але встигають оновити свій код, щоб використовувати нову функцію.
• У версії 3 ви оновлюєте атрибут як помилку, а не попередження, і оновлюєте повідомлення, щоб сказати "Ця функція застаріла. Використовуйте замість неї кращу функцію. У версії 4 цієї бібліотеки, яка буде випущена на таких і таких побачення, ця функція кине ». Користувачі, які не звернули уваги на ваше попереднє попередження, все ще отримують корисне повідомлення, яке вказує їм, як виправити проблему, і вони повинні її виправити, оскільки тепер їхній код не складається.
• У версії 4 ви змінюєте функцію, щоб вона кидала якийсь фатальний виняток, і змінюєте повідомлення, щоб сказати, що функція буде повністю видалена в наступній версії.
• У версії 5 ви видаляєте цю функцію повністю, і якщо користувачі скаржаться, добре, ви дали їм три цикли випуску справедливого попередження, і вони завжди можуть просто продовжувати використовувати версію 2, якщо вони сильно відчувають це.

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

Ви неправильно зрозуміли, що означає "застарілий". Застарілий означає:

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

_{Оксфордські словники}

За визначенням, застаріла функція все одно буде компілюватися.

Ви шукаєте видалити функцію в певну дату. Це добре. Як ви це робите, ви видаляєте його в цю дату .

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

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

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

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

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

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

Однак їх @Deprecatedможе бути достатньо. Ловіть попередження в CI і змушуйте його відмовлятися приймати збірку, якщо такі є. Це перекладає відповідальність з компілятора на ваш конвеєр збірки, але має ту перевагу, що ви можете (напів) легко змінити конвеєр збірки, додавши додаткові кроки.

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

Ви шукаєте календарі чи списки todo .

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

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

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

Один із способів задуматися над цим - це, що ви маєте на увазі під час / дату ? Комп'ютери не знають, що це за поняття: їх треба якось запрограмувати. Досить часто представляти часи у форматі UNIX «секунди з епохи», і звичайно подавати певну цінність у програму за допомогою викликів ОС. Однак, як би не було поширене таке використання, важливо пам’ятати, що це не «фактичний» час: це лише логічне уявлення.

Як зазначали інші, якщо ви створили "термін", використовуючи цей механізм, тривіально годувати в інший час і порушувати цей "термін". Те ж саме стосується і більш досконалих механізмів, таких як запитання сервера NTP (навіть через "захищене" з'єднання, оскільки ми можемо замінити власні сертифікати, органи сертифікації або навіть виправити криптовалюти). Спочатку може здатися, що такі люди винні у роботі навколо вашого механізму, але, можливо, це робиться автоматично і з поважних причин . Наприклад, добре мати відтворювані збірки , а інструменти, які допоможуть цьому, можуть автоматично скинути / перехопити такі недетерміновані системні виклики. libfaketime робить саме це,встановлює всі часові позначки файлу, функцію запису / повторення1970-01-01 00:00:01 Qemu підробляє всю апаратну взаємодію тощо.

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

Є й інші логічні уявлення про час: одне з них - версія програмного забезпечення (або ваша програма, або деяка залежність). Це більш бажане подання на "кінцевий термін", ніж, наприклад, час UNIX, оскільки він більш специфічний для того, що вам важливо (зміна наборів функцій / API) і, отже, менше шансів наткнутися на ортогональні проблеми (наприклад, зіткнення з часом UNIX для обробка терміну може призвести до порушення файлів журналів, завдань із запиту на керування, кешів тощо).

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

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

Важливим питанням підходу "тягнути" є те, чи вважається версія залежності "одиницею" ( функціональності ) чи, отже, заслуговує на тестування; чи це просто "приватна" деталізація реалізації, яку слід використовувати лише як частину тестів фактичної одиниці ( на функціональність ). Я б сказав: якщо відмінність між версіями залежності справді зараховується як особливість вашої програми, тоді робіть тест (наприклад, перевіряючи, чи версія Python>> = 3.x). Якщо ні, то не вартододайте тест (оскільки він буде крихким, неінформативним та надмірно обмежуючим); якщо ви керуєте бібліотекою, тоді рухайтесь по маршруту "push". Якщо ви не керуєте бібліотекою, тоді просто використовуйте будь-яку версію: якщо ваші тести проходять, обмежувати себе не варто; якщо вони не пройдуть, то це ваш "термін" прямо там!

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

Кожен із них буде застосований за різних обставин.

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

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

Однією з вимог є введення поняття часу у складання. У C, C ++ або іншими мовами систем , які використовують C-подібний препроцесор / побудувати ¹ , можна було б ввести мітку часу через визначає для препроцесора під час збирання: CPPFLAGS=-DTIMESTAMP()=$(date '+%s'). Це, швидше за все, станеться в makefile.

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

#if TIMESTAMP() == 0 || TIMESTAMP() > 1520616626
#   error "The time for this feature has run out, sorry"
#endif

Крім того, можна просто "визначити" код, про який йде мова, коли настає час. Це дозволило б програмі компілюватись за умови, що її ніхто не використовує. Скажімо, у нас є заголовок, що визначає api, "api.h", і ми не можемо зателефонувати old()через певний час:

//...
void new1();
void new2();
#if TIMESTAMP() < 1520616626
   void old();
#endif
//...

Подібна конструкція, ймовірно , усунути old()«s тіло функції з деякого вихідного файлу.

Звичайно, це не дурень; можна просто визначити старий TIMESTAMPу випадку згаданого в іншому місці аварійного будівництва в п'ятницю. Але це, я думаю, досить вигідно.

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

У Visual Studio можна встановити сценарій попереднього збирання, який видаляє помилку після певної дати. Це запобіжить компіляцію. Ось сценарій, який видаляє помилку 12 березня 2018 року або пізніше ( взято звідси ):

@ECHO OFF

SET CutOffDate=2018-03-12

REM These indexes assume %DATE% is in format:
REM   Abr MM/DD/YYYY - ex. Sun 01/25/2015
SET TodayYear=%DATE:~10,4%
SET TodayMonth=%DATE:~4,2%
SET TodayDay=%DATE:~7,2%

REM Construct today's date to be in the same format as the CutOffDate.
REM Since the format is a comparable string, it will evaluate date orders.
IF %TodayYear%-%TodayMonth%-%TodayDay% GTR %CutOffDate% (
    ECHO Today is after the cut-off date.
    REM throw an error to prevent compilation
    EXIT /B 2
) ELSE (
    ECHO Today is on or before the cut-off date.
)

Обов’язково прочитайте інші відповіді на цій сторінці, перш ніж використовувати цей сценарій.

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

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

Для рішення на основі SCM я припускаю, що ви використовуєте git та git-flow. (Якщо ні, то логіка легко адаптується до інших VCS). Створіть нове відділення postDeprecated. У цій гілці видаліть увесь застарілий код і починайте працювати над видаленням будь-яких посилань, поки він не складеться. Будь-які нормальні зміни продовжують вносити у masterвідділення. Продовжуйте об'єднання будь-яких не-застаріле пов'язані зміни коду в masterзадній частині в postDeprecatedцілях зведення до мінімуму проблеми інтеграції.

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