В прошлой статье я рассказывал, как настроил личный iptables и перешел в режим Default Deny, чтобы отбиться от внешних DDoS-атак (коллег, пустых встреч и спама). Периметр я защитил, входящий трафик почистил. Uptime вырос.

Казалось бы — живи и радуйся. Но я заметил странную вещь: снаружи тихо, а сервер все равно греется. Я заглянул внутрь контейнера и понял: проблема не во входящих пакетах. Проблема в архитектуре самого приложения.

Парадокс: я могу спроектировать архитектуру, которая выдержит падение дата-центра. Я могу дебажить race condition в многопоточном приложении. Но когда мне нужно позвонить в страховую или выбрать отель для отпуска, я впадаю в ступор.

Мой личный бэклог забит задачами типа «разобраться с налогами» и «начать бегать», которые висят там с 2019 года. Я переношу их из спринта в спринт, испытывая фоновое чувство вины.

В какой-то момент я понял: это не лень. И это не «отсутствие мотивации». Это классический Technical Debt (Технический долг), только не в репозитории, а в нейросети.

И проценты по этому долгу я плачу самым дорогим ресурсом — своей когнитивной емкостью.

Архитектура проблемы: Откуда берется Legacy в голове

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

• «Захардкожу этот конфиг, потом вынесу в переменные».

• «Напишу без тестов, потом покрою».

В жизни мы делаем то же самое. Мы пишем «временные костыли», которые становятся фундаментом нашей личности.

Пример 1: «Костыль избегания» Вам нужно поговорить с токсичным коллегой. Это сложно (дорогой рефакторинг отношений). Вы выбираете «быстрое решение»: промолчать и сделать за него. Результат: Вы сэкономили 10 минут сейчас, но внесли баг в архитектуру. Теперь система знает: «Чтобы не было конфликта, работай за двоих». Этот костыль начинает жрать ваш ресурс каждый день.

Пример 2: «Утечка ресурсов» (Unclosed Resources) Вы пообещали себе (или кому-то) что-то сделать. «Выучить Rust», «Починить кран». Вы не делаете. В коде, если вы открыли соединение с БД и не закрыли его, это соединение висит и жрет память. В мозге — то же самое (Эффект Зейгарник). Каждое «надо бы» — это открытый сокет. Когда их становится 500, сервер ложится от Too Many Open Files.

Interest Rate: Цена обслуживания

Самое страшное в техдолге — это проценты. Мартин Фаулер писал: «Главная проблема техдолга не в том, что код некрасивый. А в том, что добавление любой новой фичи становится экспоненциально сложнее».

То же самое с людьми. Когда у вас накопился «Психологический Техдолг»:

1. Высокий Time-to-Market: Чтобы сделать простую задачу (помыть посуду), вам нужно преодолеть чудовищное сопротивление.

2. Низкая отказоустойчивость: Любой мелкий баг (нахамили в магазине) вызывает Kernel Panic (истерику), потому что система и так работала на пределе.

3. Невозможность масштабирования: Вы не можете взять ответственность за семью или новый проект, потому что ваш «монолит» и так еле дышит.

Мы пытаемся лечить это «тайм-менеджментом» (оптимизацией процессов). Но нельзя оптимизировать процесс, если архитектура гнилая. Нужен Рефакторинг.

Алгоритм: Refactoring Strategy

Как мы разгребаем техдолг в проекте? Мы не переписываем всё с нуля (это путь к смерти проекта). Мы выделяем квоту времени в каждом спринте.

Вот мой протокол рефакторинга личности:

Шаг 1. Code Review (Инвентаризация)

Выпишите все свои «висяки». Вообще все.

• Обещания себе и другим.

• Недоделанные курсы.

• Обиды (да, это тоже незакрытые транзакции).

• Вещи, которые «надо бы» починить/купить.

У меня получилось 140 пунктов. Это был мой legacy-код.

Шаг 2. Deprecation (Списание)

В коде мы помечаем устаревшие методы как @Deprecated. Мы признаем: «Мы больше это не поддерживаем». Посмотрите на свой список. 50% этих задач уже не актуальны. Вы хотели выучить испанский 3 года назад. Вам это всё еще надо? Честно? Если нет — официально «убейте» задачу. Скажите себе: «Проект закрыт. Поддержка прекращена. Ресурсы освобождены». Это дает колоссальный приток энергии.

Шаг 3. Quick Fixes (Закрытие уязвимостей)

Найдите задачи, которые занимают меньше 15 минут, но висят месяцами (записаться к врачу, оплатить штраф). Выделите один «Спринт Чистки» (суббота) и закройте их пачкой. Вы удивитесь, насколько тише станет в голове.

Шаг 4. Rewrite (Переписывание ядра)

Это самое сложное. Это работа с «багами» характера (например, «Я не умею говорить НЕТ»). Тут нужен не фикс, а переписывание модуля. Я использую метод Протокол 3.16: Рефакторинг Убеждений.

1. Найти старый скрипт («Если откажу — меня отвергнут»).

2. Написать новый скрипт («Отказ — это защита моих границ»).

3. Тестировать на проде (в жизни) малыми итерациями.

Вывод

Вы не «ленивый». Вы просто поддерживаете огромную кодовую базу говнокода, который сами же написали (или унаследовали от родителей). Ваша апатия — это защита сервера от перегрева.

Перестаньте требовать от себя фич. Остановите разработку. И займитесь техдолгом. Потому что, как говорят у нас: «Если вы не платите за техдолг, вы платите за него своей стабильностью».

P.S. Инструменты

Я задокументировал свои методы рефакторинга в виде сухих алгоритмов (без воды и «успешного успеха»). Всё это есть в гайде «System Diagnostics» в моем канале (ссылка в профиле).

• Как провести инвентаризацию (RAM Dump).

• Как безопасно «депрекейтить» обязательства.

• Как переписать скрипты поведения.

Я не психолог, я инженер. И я верю в документацию, а не в магию.