🔧 Одностраничное соглашение - фундамент качества
🔥 Приходя на "горящий" проект хочется немедленно включить DevOps-турбо-режим: настроить CI, написать сотни автотестов...
Но "вкрутить Jenkins" - не значит навести порядок. Роботы без контекста - просто тревожные лампочки. Инструменты требуют время на установку и обучение. Команде непонятно, зачем "роботы" мешают им писать код. Первые замечания от статического анализатора будут восприняты как обвинение "вы все пишете неправильно".
🧭 Первый бесплатный шаг Начни с диалога и одностраничного соглашения о разработке. Такое соглашение может поместиться на одну страницу и сразу снять большинство вопросов: 1. Цель. Объясни единые договоренности о методах внесения изменений в поддерживаемые конфигурации чтобы сократить трудозатраты на обслуживание. 2. Стандарты 1С. Система стандартов и методик разработки уже существует. Это база, на которую будет опираться команда. 3. Маркеры в коде. Маркеры в изменениях кода вендора помогут контролировать сохранения модификаций при больших объединенинях и анализе изменений. 4. Один коммит - одна задача. Комментарий к помещаемому изменению должен содержать номер задачи и общее описание изменения. 5. Префиксы для новых объектов. Одинаковые префиксы в виде кода проекта или компании, как и маркеры в коде, позволят легко отличить проектные решения от рудиментов неудачных обновлений. 6. Модификация только в коде. Использование общих переопределяемых модулей для модификаии форм упростит и ускорит обновления. 7. Настройка поддержки типовых объектов. Снимай замок только с изменяемых объектов. Сразу будет видно объекты без наших модификаций, а сонар проигнорирует такие объекты, позволив сконцентрироваться только собственных изменениях. Договор фиксирует идею. Когда позже появится CI, он лишь формализует то, о чем команда уже договорилась – робот подтвердит договоренности, а не "обрушит" красными ошибками. Документ собирается за час, согласовывается командой и заменяет бесконечные "а давайте вот так" одним понятным ориентиром.
📊 Почему это работает • Единый канон убирает бессмысленные споры о "верном" стиле, договорились - делаем. • Простая трассировка позволяет быстро понять, кто и зачем изменил код - ревью и аудит ускоряются. • Метки и префиксы сводят к минимуму "археологию" и сокращают время обновления: нетиповые фрагменты видны сразу. • Границы ответственности ясны: одна задача - один коммит - одна причина для отката, если что‑то пошло не так. • Экономия времени - меньше поисковых вопросов, меньше ручного слияния, больше часов на развитие продукта.
Одна страница договоренностей не ускорит релизы сама по себе, но снимет хаос и освободит часы команды на реальные улучшения вместо повторного "археологического" труда.
