Как внедрять линтеры (2/2) 1. Выберите инструмент Для начала возьмите самый популярный или рекомендуемый создателями языка. Как правило, базовые потребности они закрывают. 2. Подключите линтер к проекту Убедитесь, что линтер подключается на машине нового разработчика автоматически. Большинство платформ предоставляют анализаторы в виде зависимостей, а инструменты поддерживают шаринг настроек через git. Если требуется ручная настройка, включите ее в онбординг. Правила анализа на данном этапе лучше оставить пустыми или включить 1-2 правила для теста. 3. Встройте выполнение линтера в CI Без CI разработчики будут забывать выполнить линтер вручную и не качественный код будет просачиваться в master. 4. Постепенно включайте правила и настраивайте их под команду За основу лучше взять готовый пресет, поставляемый с инструментом. Включение очередного правила лучше сливать в master через отдельную ветку без функциональных изменений. Так вы убедитесь, что вся команда получит новую версию настроек как можно скорее. СОВЕТЫ ⚠️ Избегайте уровня warning Старайтесь принимать «бинарное решение»: либо считаем несоблюдение правила ошибкой (error), либо выключаем его (none). Warning подразумевает, что человеку необходимо принять решение, а наша цель - избавиться от ручного труда. Плюс они подобны баннерам: со временем их перестают замечать. ⚡️ Любое решение сейчас лучше, чем идеальное решение никогда Цель не в том, чтобы выбрать самые правильные настройки. Цель в том, чтобы договориться до единых подходов. Если коллеги не согласны с предлагаемыми настройками, не слишком старайтесь переубедить их. Мнения могут отличаться, но главное - чтобы коллеги согласились соблюдать принятые правила. Disagree, but commit! 🔒Не старайтесь стандартизировать все Стандартизация имеет свои плюсы, но часто сопряжена с неудобством в каждом конкретном случае. Если допустимы разные варианты, а мнения расходятся, можно вовсе отключить правило. Пример к последним двум пунктам В .NET запятая после последнего аргумента инициализатора является опциональной. В одной из команд мы договорились не ставить ее, в другой - ставить обязательно. А в третьей - вовсе решили, что нас устраивает любой вариант и отключили правило. Все варианты имеют свои плюсы и минусы, приводят к разным последствиям. Неважно какой был выбран, главное - IDE автоматически форматировала код исходя из настроек линтера. 🥸 Не проходите мимо некорректного правила Худшее, что можно сделать - это начать подстраивать код под инструмент, когда инструмент не прав. Если сталкиваетесь с ошибкой, то постарайтесь быстро внести изменения в настройки в неблокирующем режиме. В «Мой спорт» я внедрил такой подход: если линтер не прав, то разработчик пишет в общий чат предложение по изменению настроек. Если от тимлидов возражений не поступает - вносит изменения в настройки в своей ветке. ⏳Не ждите позитивных улучшений в краткосрочной перспективе Помните, что настройка линтеров - это инвестиция, а значит окупается в долгосрочной перспективе. Первое время, неудобства будут обнаруживаться спонтанно. Будьте готовы реагировать оперативно. 🙏 Подготовьтесь к критике и просьбам сделать исключение «Нам сейчас очень надо», «нет времени исправлять», «сейчас зарелизим, потом поправим» и подобные фразы вы будете слышать очень часто. Проявите эмпатию, но не позволяйте исключениям свести на нет ваши усилия. Иначе получите exceptional debt (см. The Elegant Puzzle). Описанным я пользовался много раз Самый показательный пример из моей практики - внедрение SonarQube в «Мой спорт». Встроив его в CI, я снял с себя необходимость вручную контролировать выполнение архитектурных правил. Накопипастить код и не покрыть его тестами, сделать класс с 10ю зависимостями на 700строк кода и т.д. стало невозможно. CI не пропустит такую ветку. Дополнительный профит: правила перестали восприниматься как «бюрократия». Если раньше мне приходилось выступать источником негативного фидбека, то теперь за меня это делает CI. А с ним спорить бесполезн