Представьте: вы копаетесь в старой кодовой базе и натыкаетесь на пыльный модуль с надписью «НЕ ТРОГАТЬ — РАБОТАЕТ С 2012 ГОДА». Мы все бывали в такой ситуации. Программное обеспечение не покрывается плесенью, как хлеб, но оно определённо устаревает по-своему. Сегодня мы открываем дебаты: стоит ли устанавливать сроки годности для нашего кода? Приготовьте свой любимый напиток с кофеином — будет горячо.

Почему сроки годности нужны не только йогурту

Современное программное обеспечение — это тикающая бомба замедленного действия зависимостей. Рассмотрим:

  • 87% приложений содержат устаревшие библиотеки с известными уязвимостями.
  • В среднем JavaScript-проект имеет 79 транзитивных зависимостей.
  • Обслуживание устаревших систем обходится предприятиям на 23% дороже ежегодно.
graph TD A[Новая функция развернута] --> B[Обновлены зависимости] B --> C{Через 3–6 месяцев} C -->|Пренебрежение| D[Уязвимости в системе безопасности] C -->|Обслуживание| E[Стабильная система] D --> F[Накопление технического долга]

Безопасность — не единственная жертва. Пытались ли вы запустить приложение Ruby on Rails 3 в 2025 году? Это всё равно что попытаться завести Model T с помощью USB-кабеля. Устаревшие зависимости превращают некогда блестящий код в цифровое болото.

Аргументы в пользу сроков годности кода

Давайте поспорим: сроки годности заставляют нести ответственность. Вот как реализовать их без хаоса:

Шаг 1: Проверка срока действия версии

Добавьте этот декоратор Python в критические модули:

from datetime import datetime
def expire_by(date_str):
    def decorator(func):
        def wrapper(*args, **kwargs):
            if datetime.now() > datetime.strptime(date_str, "%Y-%m-%d"):
                raise DeprecationError(
                    f"{func.__name__} истёк {date_str}. Обновите немедленно!"
                )
            return func(*args, **kwargs)
        return wrapper
    return decorator
# Использование:
@expire_by("2025-12-31")
def process_payments():
    # Ваша логика обработки платежей здесь

Шаг 2: Отслеживание истечения срока действия зависимостей

Вставьте это в ваш CI/CD-пайплайн:

# .github/workflows/expiry_check.yml
name: Проверка истечения срока действия зависимостей
on: [push, schedule]
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Проверка истёкших зависимостей
        run: |
          npm install -g depcheck
          depcheck --fail-on=expired          
        if: ${{ failure() }}
        run: echo "##vso[task.logissue type=error]Обнаружены истёкшие зависимости!"

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

Контраргумент: Когда бессмертие имеет значение

Не весь код должен иметь срок годности. Рассмотрим:

  • Медицинские устройства, работающие на 20-летней прошивке.
  • Космические зонды, для обновления которых требуется межзвёздная доставка FedEx.
  • Банковские мейнфреймы, где действует принцип «если работает, не чини».

Как сказал мне однажды ворчливый старший разработчик: «Парень, IRS до сих пор работает на COBOL. Твой JavaScript-фреймворк не так важен». Touche.

Средний путь: Выборочный срок службы

Вместо общих сроков годности реализуйте зависимость долговечности от контекста:

stateDiagram-v2 [*] --> ОценкаРисков ОценкаРисков --> ВысокийРиск: Обработка платежей ОценкаРисков --> НизкийРиск: Внутренние утилиты ВысокийРиск --> ОбязательноеИстечение: Цикл 6 месяцев НизкийРиск --> ФакультативноеОбслуживание: «Нет жёсткого срока годности»

Практическая реализация

  1. Классификация по уровню риска:
    • 🚨 Красная зона (безопасность/чувствительные данные): Жёсткие сроки годности.
    • 📊 Жёлтая зона (внутренние инструменты): Предупреждающие баннеры через 18 месяцев.
    • 🌱 Зелёная зона (статические утилиты): Нет срока годности.
  2. «Наследие завещания»:
    ## ИНСТРУКЦИИ ДЛЯ НАСЛЕДИЯ
[Название системы]: Обработчик платежей v2.3
Срок годности: 2026-06-30
Система-преемник: /payments/v3
Контакт: [email protected]
Режимы отказа:
  - После 2026-07-01 будет отклонять транзакции
  - Ежемесячно во время льготного месяца логирует «ИСТЁКШИЙ СИСТЕМА»
    Храните это в /system_wills/README.md в каждом репозитории.

Почему это не просто занудство

Вспомните утечку данных Marriott на 4,6 миллиарда долларов, вызванную неустановленными патчами для устаревших систем. Или последствия Log4j, превратившие системных администраторов в паникующих бариста. Сроки годности не о том, чтобы убивать старый код — они о уважении к жизненному циклу.

Когда я борюсь с конфигурацией webpack 2017 года, которая теперь напоминает иероглифы, я вспоминаю: программное обеспечение — это не вино. Оно не улучшается с возрастом. Что, если бы мы относились к коду как к молочным пакетам? Штампы «годен до» могли бы просто спасти нас от нас самих.

Ваш ход, разработчики. Будем ли мы продолжать строить цифровые пирамиды, надеясь, что они простоят тысячелетия? Или мы примем запланированный износ как акт цифровой гигиены? Раздел комментариев ждёт ваших горячих комментариев…