Должны ли стандарты кодирования применяться сервером непрерывной интеграции?

Должны ли стандарты / стиль кодирования быть применены сервером непрерывной интеграции, на котором запущены инструменты статического анализа (например, PMD, StyleCop / FxCop) и не выполняется сборка, если стандарты не соблюдаются? Какие типы правил не должны использоваться для сбоя сборки?

Стандарты кодирования должны быть там по причине ... и несоблюдение должно быть проверено.

Однако не все нарушения следует рассматривать как ошибки - так же, как не все нарушения компиляции. Там, где вы проводите черту, должно быть решение компании и инструмента.

Например, MISRA определяет свои правила как Обязательные и Консультативные ... Я бы предположил, что Консультативные советы позволят продолжить сборку.

Это не совсем неслыханно, и вы узнаете, будет ли это работать для вас, только попробовав это. Есть некоторые шаги, которые вы могли бы предпринять до этого.

Сначала команда должна определиться со стандартами вместе. Затем следует использовать такие инструменты, как ReSharper, чтобы сообщить разработчикам, что они не придерживаются стандартов. Проведение экспертных проверок по каждой задаче может помочь в дальнейшем.

После того, как эти шаги были предприняты, можно было бы рассмотреть возможность поставить стандартные проверки кодирования на CI-сервер. Тем не менее, все равно следует учитывать, стоит ли прерывать сборку из-за несоблюдения стандартов кодирования. Риск состоит в том, что у вас будет много неработающих сборок, которые могут ослабить значение поврежденной сборки.

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

Должны ли стандарты / стиль кодирования быть применены сервером непрерывной интеграции, на котором запущены инструменты статического анализа (например, PMD, StyleCop / FxCop) и не выполняется сборка, если стандарты не соблюдаются?

Эти непрерывные проверки интеграции должны быть очень, очень быстрыми. Любые существенные задержки будут означать, что ваши программисты будут комментировать и потерять контроль над своим мыслительным процессом, ожидая результатов. Сделайте это дольше, и они возьмут на себя и выпьют чашку кофе или пообщаются со своими коллегами по офису о последних неудачных выступлениях некоторых спортивных команд. Эти задержки крайне контрпродуктивны. Некоторые вещи лучше оставить для ночной сборки или проверки кода.

Какие типы правил не должны использоваться для сбоя сборки?

Субъективные, для начала. Как вы применяете правило «Код должен быть самодокументированным или хорошо прокомментированным»? Правило «без магических чисел»? Это те вещи, которые лучше оставить для обзора кода.

Другая категория - это нарушения правил, которые уже были отменены. Учитывая любую значительную кодовую базу, неизбежно будет некоторый кусок кода, в котором нарушение стандарта - это как раз то, что нужно делать.

В рамках Плана повышения качества программного обеспечения мы недавно написали серию анализаторов кода для интеграции в наш процесс сборки.

Мы много строим, будучи PHP-приложением, никакой реальной компиляции нет, поэтому сборка действительно является модульным тестом / статическим анализом / раннером, и мы можем позволить себе потратить на это несколько циклов.

У нас были некоторые проблемы с качеством кода, и унаследованный код с множеством проблем.

Начав с того, что если он не завершится фиксацией, он будет проигнорирован, мы начали подтверждать коммиты в соответствии с нашим «желаемым» стандартом кодирования, а неудачные коммиты с ошибками, которые не соответствуют стандарту.

Техническое обслуживание было приостановлено, даже самое простое исправление устаревшего компонента требовало от разработчика переформатирования огромного количества исходного кода, и сборка чаще всего нарушалась. Излишне говорить, что мы изменили ошибки на предупреждения, и теперь они игнорируются и «в основном» бессмысленны.

Так что я бы сказал это (извлеченный из тяжелого опыта).

Убедитесь, что стандарт вашей кодовой базы достаточно близок к стандарту, который вы применяете, чтобы вам не требовалось, чтобы dev быстро переформатировал объемы кода. Или .. Вы готовы и ожидаете увеличения усилий.

Будучи небольшой командой с огромными требованиями к доставке, мы не могли позволить себе переключиться на огромную операцию по перефакторингу. Наши стандарты кодирования в настоящее время в основном обрабатываются вручную, и наследие переписывается как часть плана постоянного улучшения.

Когда я сказал, что предупреждения «в основном» бессмысленны, мы теперь используем их для записи статистики, которая позволяет нам измерять значения kpi, которые должны постоянно улучшаться.

Когда мы снова приведем в исполнение сниффы кода, мы начнем светить и введем несколько сниффов за раз, пока мы не введем стандарт в действие.

Это будет зависеть от вашей конечной цели и стратегии .

Применение всех упомянутых стандартов в CI-сервере может показаться очень прибыльным. Однако это может оказаться непрактичным для большой (более 6 разработчиков) команды разработчиков, если это делается при каждой фиксации на сервере. Ожидание ответа сервера после фиксации НЕ должно быть длительной задержкой. Это может привести к простоям.

Однако вполне законно блокировать коммит, если код (на самом деле набор изменений) имеет проблемы с зависимостями или не компилируется. Однако сбой кода из-за разметки кода и некоторых соглашений об именах может быть слишком серьезным и не является существенным ограничением для правил фиксации сервера CI.

Но это очень вероятно, будет полезным правилом, если применять его во время вечерней сборки.

Кроме того, инструменты рефакторинга могут помочь в реализации и изучении стандартов, таких как использование Resharper или JustCode разработчиками.