# Побудувала механізм перевірок репозиторію — 268 зареєстрованих перевірок коміту, 277 правил лінтингу та 15 власних правил ESLint — а також 146 тестів самих перевірок, щоб стандарт тримала збірка, а не код‑рев'ю. 2025 **Ситуація.** Стандарти, записані в настановах для учасників проєкту, — лише побажання. З ними всі згодні, а потім настає п'ятниця, зміна маленька, і настанови програють. Планка нульових попереджень могла втриматися лише за умови, що її триматиме щось, окрім доброї волі, — а лінтери, що йдуть у комплекті з кожною мовою, далеко не охоплюють специфічних для проєкту правил, які насправді мають значення: тих, що описують, як має працювати саме ця кодова база. **Завдання.** Важливі для проєкту правила мали стати виконуваними, щоб порушення будь‑якого з них зупиняло коміт, а не чекало на рецензента, якому вистачить часу й пам'яті це помітити. **Дія.** З цього виріс цілий рушій захисних перевірок. Це 274 скрипти перевірок, із них 268 зареєстровано в хуках комітів, а поруч — 277 лінтерів на JavaScript, 96 валідаторів на shell і 17 на Python, які стежать за тим, до чого готовим інструментам байдуже: що міграцію можна відкотити, що ключ перекладу існує в обох локалях, що зареєстрований маршрут є в описі OpenAPI, що ніхто тихцем не придушив попередження прямо в коді. П'ятнадцять власних правил ESLint тримають у TypeScript патерни, прийняті в проєкті. Одне правило варто назвати окремо: будь‑який коміт із префіксом fix: мусить містити тест, який без цього виправлення падає, — тож виправлена вада лишається виправленою. А оскільки зламана перевірка гірша, ніж її відсутність, — вона пропускає все, і ніхто про це не дізнається, — самі перевірки мають 146 власних тестів. **Результат.** На рев'ю час тепер іде не на механіку, а на проєктування, бо механічні зауваження машина висловила ще до того, як гілку відправили в репозиторій. Компроміс реальний, і про нього варто сказати прямо: комітити повільно, а погано написана перевірка, яку доводиться обходити, справді доводить до сказу. Ті 146 тестів існують саме тому, що так уже траплялося. --- - Роль: Керівник розробки - Категорії: [DevOps](https://advisory.engineer.company/uk/categories/devops/), [Автоматизація та CI/CD](https://advisory.engineer.company/uk/categories/automation/), [Тестування та QA](https://advisory.engineer.company/uk/categories/testing/), [Технічне лідерство](https://advisory.engineer.company/uk/categories/technical-leadership/), [Документація](https://advisory.engineer.company/uk/categories/documentation/) - Послуги: [DevOps та автоматизація CI/CD](https://advisory.engineer.company/uk/services/devops-cicd/), [Технічне лідерство та консалтинг](https://advisory.engineer.company/uk/services/technical-leadership/), [Технічна документація](https://advisory.engineer.company/uk/services/technical-documentation/)