Ревью и шаблон описания изменения
Директивный
Правило
Заголовок раздела «Правило»Каждое изменение (своё или подрядчика) проходит ревью и оформляется по единому шаблону описания. Без заполненного описания MR не ревьюится — «смотри код, там всё понятно» не принимается.
Шаблон описания изменения (кладётся в репозиторий как шаблон MR/PR):
- Задача / причина:- Затронутые объекты:- Тип: feature / bugfix / refactor / migration- Риск: низкий / средний / высокий- Как проверить:- Как откатить:- Миграции/обновление ИБ: есть/нет (идемпотентно?)- Безопасность: секреты? внешние ресурсы?- Производительность: влияние на горячие места?Фокус ревьюера (то, что не ловит линтер):
- Безопасность — секреты, техпользователь, обоснованность COM/внешних ресурсов;
- Производительность — перф-прогон горячих мест, запросы в цикле;
- Обработка ошибок — нет молчаливых исключений;
- Транзакции — короткие, каноничный шаблон;
- Совместимость — доработка через расширение/точки переопределения;
- Откат — описан и реалистичен.
Повторяющиеся замечания ревью собираются в базу и по возможности уводятся в диагностики линтера — ревьюер не должен из раза в раз писать одно и то же руками.
Ревью — единственный рубеж для дефектов, которые не автоматизируются: неверная бизнес-логика, дыра в правах, деградация проведения. Шаблон описания — это ещё и страховка сопровождения: через полгода «как откатить» и «как проверить» читает дежурный, а не автор. Для аутсорса шаблон фиксирует передачу знания: контекст задачи остаётся в MR, а не в личном чате с уволившимся менеджером.
Когда не применять
Заголовок раздела «Когда не применять»Исключений по существу нет. Для тривиальных изменений (опечатка в НСтр, правка комментария) допустим сокращённый шаблон — но ревью и зелёный CI обязательны.