tech-audit

Tech Audit — ловушки и anti-patterns

Идея и цели

Аудит только кода без анализа идеи

Плохо: сразу открыть diff и комментировать строки кода Правильно: начать с "ЧТО решаем, ЗАЧЕМ, для КОГО" — потом переходить к реализации Почему: идеально реализованная ненужная фича хуже плохо реализованной нужной. Проблема уровня идеи не чинится code review

Нет ответа "что будет если НЕ делать"

Плохо: принять задачу как данность — "надо значит надо" Правильно: явно оценить cost of inaction — текущие потери, risk exposure, альтернативы Почему: без baseline невозможно оценить ROI изменения. Иногда "не делать" — лучшее решение

Подход и альтернативы

Подход принят без сравнения альтернатив

Плохо: "используем Event Sourcing" без объяснения почему не CRUD или Change Data Capture Правильно: таблица альтернатив с trade-offs — какие варианты рассмотрены и почему отброшены Почему: без альтернатив невозможно оценить решение. Может быть выбран overengineered подход для простой задачи

Нет матрицы "было - стало"

Плохо: описать только новое поведение, без сравнения с текущим Правильно: таблица сценариев (happy/error/edge) с колонками было/стало/риск Почему: изменения семантики невидимы в diff. Ошибка в edge case проявится в production, а не в code review

Breaking changes не зафиксированы

Плохо: "обратная совместимость сохранена" без доказательств Правильно: явный список потребителей API, проверка каждого контракта на совместимость Почему: "совместимо" часто означает "я не нашёл несовместимость". Потребители могут зависеть от undocumented behavior

Компонентная база

Компоненты без проверки лимитов

Плохо: "используем Redis для очередей" без проверки persistence гарантий и memory limits Правильно: проверить changelog, known issues, версию, лимиты каждого ключевого компонента Почему: компонент может не поддерживать то, что от него требуют. Redis Pub/Sub теряет сообщения при disconnect — не замена RabbitMQ

Совместимость компонентов "по умолчанию"

Плохо: два ORM, два кэша, два механизма транзакций — "разберёмся потом" Правильно: явно проверить конфликты — 2 transaction manager, distributed cache + local cache, два retry policy Почему: каждый компонент корректен по отдельности. Конфликт проявляется только при интеграции — deadlock, stale data, double processing

Deprecated зависимость не обнаружена

Плохо: взять библиотеку из примера в Stack Overflow без проверки актуальности Правильно: проверить последний release, open issues, migration guide, статус поддержки Почему: deprecated компонент = технический долг с момента интеграции. Security patches прекращаются, community уходит

Код и реализация

Аудит кода без предварительных фаз

Плохо: ревьюить PR без понимания идеи, подхода и компонентной базы Правильно: code audit после анализа идеи, подхода, компонентов — с контекстом Почему: без контекста code review превращается в line-by-line nit-picking. Архитектурные проблемы невидимы на уровне строк

Вердикт и рекомендации

Вердикт без оценки impact

Плохо: "есть риск race condition" без оценки вероятности и последствий Правильно: для каждого риска — вероятность, impact, митигация; вердикт APPROVE/CONCERN/REJECT Почему: без impact assessment все риски выглядят одинаково. Race condition раз в год в логировании и race condition в платежах — разные приоритеты

APPROVE с открытыми блокирующими вопросами

Плохо: "APPROVE, но надо проверить thread safety и добавить retry" — это не APPROVE Правильно: если есть блокирующие замечания — CONCERN. APPROVE только когда risk acceptable Почему: APPROVE с оговорками игнорируется. Разработчик видит "APPROVE" и мержит, замечания теряются

Нет явного Out of Scope

Плохо: аудит закончен, но непонятно что проверено, а что нет Правильно: явно зафиксировать что не анализировалось — performance, security, infrastructure Почему: отсутствие замечаний по security != "security проверена". Stakeholders должны знать границы аудита