Чек-лист самопроверки

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору

Загрузка вопросов…

Проверьте себя после статей 1–4 и итогов. Вопросы с пометкой ↗ углубляются в других разделах энциклопедии (инфраструктура, тестирование, архитектура) — здесь достаточно общего понимания связи.

Как пользоваться чек-листом

Отвечайте вслух или письменно, своими словами — не копируйте определения. Если ответ длиннее одного предложения и содержит пример из практики («у нас монолит, вынесли auth через Nginx») — вы усвоили тему. Под каждым блоком есть развёрнутые подсказки в раскрывающихся секциях.

---

Определения и оценка состояния

Опора: статья 1

1. В чём разница между «легаси как наследие» и «легаси по Фезерсу»?
2. Чем «тихое» легаси отличается от «кричащего»?
3. Назовите пять признаков легаси-модуля без привязки к возрасту кода.
4. Что такое управляемое легаси и почему его не обязательно переписывать?
5. Когда код считается критическим наследием, а не просто старым?
6. Как технический долг связан с удорожанием правок в легаси? ↗ Методология PO
7. Какие риски легаси для бизнеса (простой, данные, комплаенс)?
8. Почему «нет комментариев» — слабый признак, а «комментарий противоречит коду» — сильный?

---

Понимание системы

Опора: статья 2

9. Какие этапы реверс-инжиниринга вы выполните перед первой правкой?
10. Что можно извлечь из git log / git blame в обрезанном репозитории?
11. Зачем интервью с поддержкой, если есть исходники?
12. Какие четыре типа диаграмм полезны для легаси и зачем каждый?
13. Чем статический анализ бинарника отличается от динамического?
14. Что зафиксировать в документе перед изменением критичного модуля?

---

Безопасные изменения

Опора: статья 3

15. Почему Фезерс говорит: «сначала тест, потом рефакторинг»?
16. Что делает характеризующий тест и чем он отличается от «правильного» unit-теста?
17. Что такое шов (seam)? Приведите пример object seam.
18. Для чего приёмы Sprout, Wrap и Scratch?
19. Как работает метод Mikado при сильной связанности?
20. Почему flaky-тест опаснее отсутствия теста?
21. На каких уровнях (unit / integration / API) вы защитите легаси без доступа к внутренностям?
22. В чём разница рефакторинга и переписывания модуля «с нуля» в одном PR?

---

Стратегии модернизации

Опора: статья 4

23. Опишите паттерн Strangler Fig и роль маршрутизатора. ↗ design/2125
24. Что такое Anti-Corruption Layer и где он стоит относительно легаси?
25. Чем clean room отличается от dirty room в процессе замены системы?
26. Когда полный rewrite оправдан? Назовите четыре критерия из статьи.
27. Что такое «защитный слой» на границе с внешним легаси-вендором?
28. Перечислите шаги универсального цикла работы с легаси (от оценки риска до фиксации знаний).
29. Как балансировать срочные баги и погашение техдолга в одном спринте?
30. Какие навыки нужны разработчику для легаси (техника + расследование + коммуникация)?
31. Как в команде формировать уважение к наследию, а не культуру «всё старое — мусор»?

---

Связь с другими темами энциклопедии

В этом разделе только обзор; детали — в специализированных главах.

32. Как документирование и ADR снижают риск при смене авторов? ↗ Техническое письмо
33. Зачем код-ревью в легаси-проекте фокусироваться на тестах и границах изменения?
34. Как анализ зависимостей помогает выбрать первый модуль для Strangler?
35. Что такое обратная совместимость API при выносе сервиса из монолита?
36. Зачем при интеграции с легаси-API может понадобиться контрактное тестирование? ↗ тестирование / микросервисы
37. Как виртуализация или контейнер помогают изолировать старое окружение для эксперимента? ↗ инфраструктура
38. Почему автоматизация деплоя легаси начинается с воспроизводимой сборки, а не с «полного CI за неделю»?
39. Как оценить стоимость владения легаси и нового решения (TCO на пальцах)?
40. В чём особенность легаси в госсекторе (регламенты, длительные контракты)?

---

Быстрые ориентиры (если застряли на вопросе)

1–8: определения — развёрнутые ответы

1. Наследие — вы не контролируете происхождение и контекст кода (чужой стек, ушедшие авторы). По Фезерсу — нет тестов, менять страшно. Оба вместе — максимальная цена правки.

2. Тихое — редко падает, но команда боится трогать. Кричащее — часто падает, обходы руками, видно в метриках и тикетах.

3. Пять признаков без «просто старый»: нет тестов; непонятные зависимости; ручной деплой; магические константы; расхождение комментария и кода; отсутствие владельца модуля.

4. Управляемое легаси: есть карта, тесты на критичном, CI. Переписывать необязательно — достаточно эволюции.

5. Критическое: нет исходников, нет истории в git, жёсткая связанность, вендор закрыл продукт.

6. Техдолг — каждая следующая фича в «грязном» модуле стоит дольше (↗ методология).

7. Риски для бизнеса: простой, утечка данных, штрафы регулятора, невозможность нанять людей под COBOL.

8. «Нет комментариев» бывает у свежего кода. «Комментарий говорит одно, код другое» — сигнал, что знание потеряно или лгут документы.

9–14: понимание системы

9. Реверс: собрать артефакты → статический/динамический анализ → гипотеза → документ → только потом правка.

10. git log — когда и зачем меняли; blame — кто писал строку (если история не обрезана).

11. Исходники не объясняют почему бизнес выбрал странное правило; поддержка помнит инциденты.

12. Четыре диаграммы: компоненты (кто с кем), последовательность (один сценарий), развёртывание (серверы), ER (данные).

13. Статический — без запуска (структура). Динамический — с запуском (логи, трассировка).

14. Зафиксировать: входы/выходы модуля, зависимости, риски, план отката, владелец.

15–21: тесты и рефакторинг

15. Фезерс: без теста вы меняете поведение вслепую; тест — страховка перед рефакторингом.

16. Characterization фиксирует как сейчас; «правильный» unit-тест проверяет как должно быть по спецификации.

17. Seam — место подмены: интерфейс, параметр, наследник, конфиг. Object seam — подмена объекта-зависимости.

18. Sprout — новый код сбоку; Wrap — обёртка вокруг старого; Scratch — переписать кусок с тестами, старое удалить.

19. Mikado: попытка → список блокеров → снять блокеры мелкими PR → снова попытка.

20. Flaky то проходит, то нет — команда перестаёт верить CI и игнорирует красные сборки.

21. Без исходников — API/e2e/контрактные тесты с фикстурами; unit — где есть швы.

22. Рефакторинг — поведение то же; переписывание в одном PR — новое поведение, высокий риск.

23–31: стратегии и команда

23. Strangler: маршрутизатор направляет часть URL в новый сервис; остальное — в монолит; доля растёт.

24. ACL стоит между вашим доменом и легаси; переводит DTO/XML в ваши типы.

25. Dirty room изучает старое и пишет спецификацию; clean room пишет новое только по спецификации.

26. Rewrite: тупик стека/ОС; лицензия; дешевле восстановить знания нельзя; цели бизнеса иначе недостижимы.

27. Защитный слой у вендора: таймауты, circuit breaker, логи, контрактные тесты на вашей стороне.

28. Семь шагов цикла из статьи 4: риск → инвентаризация → анализ → тесты → правка → наблюдаемость → знания.

29. Срочный баг — минимальный фикс + тест; долг — доля спринта или поток; фича в легаси-модуле — время на шов.

30. Техника (git, тесты, отладка) + расследование (логи, гипотезы) + коммуникация (вопросы без обвинений).

31. Уважение: code review без «всё старое — мусор»; признание скрытых контрактов; параное чтение легаси.

32–40: связь с другими темами

32. ADR и документация сохраняют почему решили так — смена авторов менее болезненна.

33. В легаси ревью смотрит: есть ли тест, не размазана ли граница изменения, не протекла ли модель легаси.

34. Граф зависимостей показывает модуль с малым «веером» — хороший кандидат для первого Strangler.

35. Обратная совместимость API — старые клиенты работают без срочного обновления при выносе сервиса.

36. Контрактные тесты ловят расхождение вашего клиента и реального ответа легаси-API.

37. Контейнер/VM поднимает старое окружение (Java 8, старая ОС) для эксперимента без риска для прода.

38. CI начинают с воспроизводимой сборки одной командой; потом тесты, потом деплой.

39. TCO: стоимость сопровождения легаси (люди, простои, лицензии) сравнивают со стоимостью миграции во времени.

40. Госсектор: регламенты, длительные контракты, «странный» код может быть следствием аудита.

---

Если больше половины вопросов без ответа — вернитесь к статье 1 или к той, что указана в подзаголовке блока.

---