В прошлой статье я рассказывал, как настроил личный iptables и перешел в режим Default Deny, чтобы отбиться от внешних DDoS-атак (коллег, пустых встреч и спама). Периметр я защитил, входящий трафик почистил. Uptime вырос.
Казалось бы — живи и радуйся. Но я заметил странную вещь: снаружи тихо, а сервер все равно греется. Я заглянул внутрь контейнера и понял: проблема не во входящих пакетах. Проблема в архитектуре самого приложения.
Парадокс: я могу спроектировать архитектуру, которая выдержит падение дата-центра. Я могу дебажить race condition в многопоточном приложении. Но когда мне нужно позвонить в страховую или выбрать отель для отпуска, я впадаю в ступор.
Мой личный бэклог забит задачами типа «разобраться с налогами» и «начать бегать», которые висят там с 2019 года. Я переношу их из спринта в спринт, испытывая фоновое чувство вины.
В какой-то момент я понял: это не лень. И это не «отсутствие мотивации». Это классический Technical Debt (Технический долг), только не в репозитории, а в нейросети.
И проценты по этому долгу я плачу самым дорогим ресурсом — своей когнитивной емкостью.
Архитектура проблемы: Откуда берется Legacy в голове
В разработке техдолг возникает, когда мы выбираем быстрое, «грязное» решение сейчас, обещая переделать «по-нормальному» потом.
-
«Захардкожу этот конфиг, потом вынесу в переменные».
-
«Напишу без тестов, потом покрою».
В жизни мы делаем то же самое. Мы пишем «временные костыли», которые становятся фундаментом нашей личности.
Пример 1: «Костыль избегания» Вам нужно поговорить с токсичным коллегой. Это сложно (дорогой рефакторинг отношений). Вы выбираете «быстрое решение»: промолчать и сделать за него. Результат: Вы сэкономили 10 минут сейчас, но внесли баг в архитектуру. Теперь система знает: «Чтобы не было конфликта, работай за двоих». Этот костыль начинает жрать ваш ресурс каждый день.
Пример 2: «Утечка ресурсов» (Unclosed Resources) Вы пообещали себе (или кому-то) что-то сделать. «Выучить Rust», «Починить кран». Вы не делаете. В коде, если вы открыли соединение с БД и не закрыли его, это соединение висит и жрет память. В мозге — то же самое (Эффект Зейгарник). Каждое «надо бы» — это открытый сокет. Когда их становится 500, сервер ложится от Too Many Open Files.
Interest Rate: Цена обслуживания
Самое страшное в техдолге — это проценты. Мартин Фаулер писал: «Главная проблема техдолга не в том, что код некрасивый. А в том, что добавление любой новой фичи становится экспоненциально сложнее».
То же самое с людьми. Когда у вас накопился «Психологический Техдолг»:
-
Высокий Time-to-Market: Чтобы сделать простую задачу (помыть посуду), вам нужно преодолеть чудовищное сопротивление.
-
Низкая отказоустойчивость: Любой мелкий баг (нахамили в магазине) вызывает
Kernel Panic(истерику), потому что система и так работала на пределе. -
Невозможность масштабирования: Вы не можете взять ответственность за семью или новый проект, потому что ваш «монолит» и так еле дышит.
Мы пытаемся лечить это «тайм-менеджментом» (оптимизацией процессов). Но нельзя оптимизировать процесс, если архитектура гнилая. Нужен Рефакторинг.
Алгоритм: Refactoring Strategy
Как мы разгребаем техдолг в проекте? Мы не переписываем всё с нуля (это путь к смерти проекта). Мы выделяем квоту времени в каждом спринте.
Вот мой протокол рефакторинга личности:
Шаг 1. Code Review (Инвентаризация)
Выпишите все свои «висяки». Вообще все.
-
Обещания себе и другим.
-
Недоделанные курсы.
-
Обиды (да, это тоже незакрытые транзакции).
-
Вещи, которые «надо бы» починить/купить.
У меня получилось 140 пунктов. Это был мой legacy-код.
Шаг 2. Deprecation (Списание)
В коде мы помечаем устаревшие методы как @Deprecated. Мы признаем: «Мы больше это не поддерживаем». Посмотрите на свой список. 50% этих задач уже не актуальны. Вы хотели выучить испанский 3 года назад. Вам это всё еще надо? Честно? Если нет — официально «убейте» задачу. Скажите себе: «Проект закрыт. Поддержка прекращена. Ресурсы освобождены». Это дает колоссальный приток энергии.
Шаг 3. Quick Fixes (Закрытие уязвимостей)
Найдите задачи, которые занимают меньше 15 минут, но висят месяцами (записаться к врачу, оплатить штраф). Выделите один «Спринт Чистки» (суббота) и закройте их пачкой. Вы удивитесь, насколько тише станет в голове.
Шаг 4. Rewrite (Переписывание ядра)
Это самое сложное. Это работа с «багами» характера (например, «Я не умею говорить НЕТ»). Тут нужен не фикс, а переписывание модуля. Я использую метод Протокол 3.16: Рефакторинг Убеждений.
-
Найти старый скрипт («Если откажу — меня отвергнут»).
-
Написать новый скрипт («Отказ — это защита моих границ»).
-
Тестировать на проде (в жизни) малыми итерациями.
Вывод
Вы не «ленивый». Вы просто поддерживаете огромную кодовую базу говнокода, который сами же написали (или унаследовали от родителей). Ваша апатия — это защита сервера от перегрева.
Перестаньте требовать от себя фич. Остановите разработку. И займитесь техдолгом. Потому что, как говорят у нас: «Если вы не платите за техдолг, вы платите за него своей стабильностью».
P.S. Инструменты
Я задокументировал свои методы рефакторинга в виде сухих алгоритмов (без воды и «успешного успеха»). Всё это есть в гайде «System Diagnostics» в моем канале (ссылка в профиле).
-
Как провести инвентаризацию (
RAM Dump). -
Как безопасно «депрекейтить» обязательства.
-
Как переписать скрипты поведения.
Я не психолог, я инженер. И я верю в документацию, а не в магию.
Автор: Systems_Engineer
