Все встречи

Встреча сообщества – 14 мая 2026

Основная тема: Контроль качества кода: линтеры, статический анализ, автоматизация CI-проверок и организационные аспекты внедрения инженерных практик в команды.
Содержание
  1. Подтемы
  2. Участники
  3. Различные мнения
  4. Основные выводы
  5. Что обсудим дальше

Подтемы и их суть

  1. Линтеры и статический анализ: где запускать

    Обсуждали три уровня запуска линтеров: IDE, pre-commit hook, CI build. Андрей считает, что IDE должна быть настроена на максимум, а commit hooks он не любит. Другие участники возражали, что pre-commit hook дает мгновенную обратную связь, а не заставляет ждать 10 минут CI-билда. Консенсус: линтеры на CI обязательны в любом случае, потому что commit hook легко обойти, а после мержа все должно проверяться независимо.

  2. Внедрение инженерных стандартов в команды

    Два подхода: постепенный (для маленьких команд с доверием) и директивный (для крупных организаций). Андрей рассказал, что в компании с 140 разработчиками любые мягкие подходы проваливались – работало только директивное «с завтрашнего дня мерж-реквесты не пройдут без линтеров». Андрей обратил внимание, что новые процессы – это отдельные проекты, и нельзя навесить на команду четыре новых практики одновременно.

  3. Теория разбитых окон и конформизм

    Если в проекте вся кодовая база структурирована и покрыта Swagger-документацией, новые разработчики автоматически следуют этим стандартам – они копируют соседний код. Андрей назвал это конформизмом: люди подстраиваются под окружение. Важно убрать психологический барьер – показать примеры на большом объеме кода, чтобы стандарт «победил количеством».

  4. JWT-токены и глобальный контекст vs явный проброс параметров

    Самая жаркая дискуссия встречи. Артур защищал подход с глобальным контекстным объектом (сервис сессии, инъекция через DI), из которого можно достать user ID в любом слое. Василий и Андрей категорически против: глобальный объект неконтролируем, скрывает зависимости, ломает тестируемость. Явный проброс параметров дает контроль через компилятор – при добавлении нового параметра все точки использования «рассыпаются» ошибками компиляции.

  5. Безопасность и аудит уязвимостей

    Обсуждали npm audit, NuGet CVE-сканирование и корпоративные репозитории артефактов. При сканировании одного проекта нашли тысячу пакетов с уязвимостями. Андрей подчеркнул, что уязвимости – это баги, и сообщество должно решать их через PR и форки. Жоха рассказал кейс, где локальная LLM с MCP-доступами провела пентест значительно эффективнее (на 80% больше находок), чем нанятая команда пентестеров.

  6. Декомпозиция и абстракции

    SonarQube хорошо воспитывает декомпозицию за счет ограничений на сложность и длину методов. Но проблема в том, что разработчики декомпозируют, чтобы удовлетворить инструмент, а не логически. Участники согласились, что один метод в 100 строк часто лучше абстракции из 10 классов.

  7. Автоматическая генерация документации

    Жоха рассказал про подход команды: локальная LLM с настроенными скиллами анализирует проект и генерирует Mermaid-диаграммы в MD-файлах. Андрей возразил: цель документации – обучение, а автогенерация не дает обратной связи о том, где люди спотыкаются. Документация – это отдельный навык и процесс, а не разовая генерация.

Участники

Андрей Организатор, линтеры и стандарты кода
Артур Внедрение стандартов в команды
Василий JWT vs явные параметры
Жоха AI-пентестинг с LLM
Денис
Ян
Паша
Аза
Луар

Различные мнения

ВопросАндрейАртурВасилий
Где линтеры?IDE на максимум, CI обязательно, директивно
Как внедрять стандарты?Постепенно через лидеров мнений, но директивно в крупных организациях
Глобальный контекст?Против, теряешь контрольЗа, удобно и простоПротив, нужен контроль компилятора
JWT в бизнес-логике?Десериализовать на входе, дальше user objectДостаем из контекстаЯвно пробрасывать параметры
Автодокументация?Скептичен, цель – обучение

Основные выводы

Линтеры и CI

Линтеры на CI – обязательный минимум. Pre-commit hooks полезны для быстрой обратной связи, но ненадежны как единственный гейт. IDE-настройки – личное дело разработчика, но на CI все должно быть строго.

Внедрение стандартов

В больших организациях эффективнее директивный подход. В малых командах работает постепенное внедрение через лидеров мнений. Каждый новый процесс – отдельный проект, нельзя навесить все сразу.

Явный проброс параметров

Контроль важнее удобства. Явные параметры дают: детерминированный код, тестируемость без моков, контроль побочных эффектов через компилятор, видимость зависимостей при ревью.

AI для пентестинга

Локальная LLM с MCP-доступами к инфраструктуре показала результаты на 80% лучше нанятой команды пентестеров при значительно меньших затратах.

Документация

Документация – это навык и процесс, а не артефакт. Нужно писать туториалы по сценариям использования, проверять их на новых людях и итерировать. Автогенерация полезна для анализа, но не заменяет осмысленную документацию.

Хотите обсудить эти темы с практикующими тимлидами?

Обсудить в Telegram
Следующая встреча

Каждую среду в 17:00 Астана, UTC+5