Как управлять качеством кода 1С, используя платформу SonarQube

30.12.19

Разработка - Рефакторинг и качество кода

При быстром росте функциональности проводить визуальный Code-Review для обнаружения некачественного кода проблематично. О том, как автоматизировать проверку качества кода 1С с помощью платформы SonarQube на конференции Infostart Event 2019 Inception рассказал ведущий разработчик компании «Командор» Олег Тымко.

Приветствую всех на конференции Infostart Event Inception. Зовут меня Тымко Олег, я работаю ведущим разработчиком в торговой сети «Командор» города Красноярска. Сегодня я хочу рассказать вам, как у нас в организации внедрялась непрерывная проверка качества кода на базе платформы SonarQube, с какими проблемами мы столкнулись, какое решение было выработано, и что в итоге у нас получилось. Но обо всем по порядку.

 

Как уследить за качеством при быстром росте функциональности?

У нас, как и в любых других организациях, для автоматизации бухгалтерского и управленческого учета, расчета зарплаты используются программные решения на базе 1С:Предприятие. Бизнес требует быстро и качественно внедрять новую функциональность в продуктив. С увеличением функциональности растет и размер проектов 1С. Соответственно, и количество кода в этих проектах. И становится актуальным следить за качеством кода, так как каждая ошибка чревата большими затратами бизнеса на ее исправление.

 

 

На слайде мы видим облако используемых решений на базе 1С:Предприятие. Их настолько много, что трудно контролировать на должном уровне качество в каждом из проектов.

 

 

С какими проблемами мы столкнулись до внедрения этого всего?

  • Первая проблема – при большом количестве разработок проблематично проводить визуальный Code-Review. Проблема ручного Code-Review не только в том, что это дорого и долго для бизнеса, но и в том, что программистам просто это делать лениво, и это их сильно утомляет. И, соответственно, их КПД падает.

  • Вторая проблема – это ошибки, о которых становится известно только на продакшене. Ладно, если это какая-то мелкая ошибка, которую быстро поправили – она никому ничего плохого не сделала. Но если эта ошибка останавливает многомиллионный оборот организации, бизнес терпит убытки, бизнес недоволен. 

  • Третья проблема в том, что в принципе нет автоматизированного контроля внутренних стандартов разработки – только с помощью Code-Review. 

  • И последнее, но не менее важное – это большие затраты на принятие работ от внешних разработчиков. 

С этим нужно было что-то делать, поэтому мы решили внедрить непрерывную проверку качества кода на базе платформы SonarQube.

 

 

В основу нашего решения легло использование SonarQube в связке с Jenkins и 1С. Об этом я сейчас все и расскажу.

 

Общая схема решения

SonarQube – это программное решение, которое позволяет непрерывно проверять качество кода. В платформе поддерживается более 27 языков программирования. С помощью плагина поддерживается и язык 1С.

 

 

Хочу рассказать о том, какое решение было выработано у нас и как всем этим пользоваться:

  • Разработчики ведут разработку в хранилище 1С, помещают туда свои изменения по каким-то задачам, по проектам и т.п.

  • Затем на стороне Jenkins (это такой сервер сборок) выполняется работа (Job), которая экспортирует историю хранилища 1С с помощью консольной утилиты GitSync в локальный Git-репозиторий.

  • Затем из локального Git-репозитория изменения отправляются в удаленный Git-репозиторий GitLab, который размещен у нас внутри организации.

 

 

  • Потом, следующая работа (Job) на стороне Jenkins анализирует изменения в этом удаленном репозитории, где у нас хранятся исходные коды конфигурации. И, если есть изменения, запускает анализ и отправляет результат в SonarQube.

 

 

  • На стороне SonarQube настроены уведомления пользователей о состоянии проектов, прохождении порогов, о новых и закрытых замечаниях. Уведомления для программистов и для ведущих разработчиков одинаковые – разница у них только в статусе прохождения порога качества.

  • Ведущие разработчики на стороне SonarQube каждый рабочий день проверяют замечания по контрольным подсистемам (в том числе по общим подсистемам) и прорабатывают их с разработчиками.
    Также ведущие разработчики контролируют увеличение дублирования в коде. Если такое дублирование ими было выявлено, то информация отправляется виновнику на исправление.

  • Также программисты сами работают с SonarQube – смотрят замечания по себе, работают над ними, тем самым, уменьшая объем работы ведущим разработчикам.

Такой процесс настроен у нас во всех основных проектах 1С.

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

 

 

Снова вернусь к самому SonarQube. А есть ли аналоги SonarQube в принципе на рынке? Да, есть – например, Solar или App scanner. Но не понятно, какую функциональность они содержат у себя на борту и сколько они будут стоить для бизнеса. 

Также есть решение на базе 1С:Предприятие – называется «1С:Автоматизированная проверка конфигураций» (в дальнейшем, я буду ее называть сокращенно 1С:АПК). Если сравнивать 1С:АПК с SonarQube, то у второго более простой и понятный интерфейс, удобный фильтр по замечаниям, есть оценка текущего состояния проекта, есть динамика изменения показателей проекта.

Если говорить о функциональности SonarQube в общем, то можно отметить следующее:

  • У SonarQube есть бесплатная поддержка кода 1С с помощью плагина SonarQube BSL Community

  • Сама платформа SonarQube имеет бесплатную версию Community Edition – не нужно сразу покупать Enterprise или Develop-версию. 

  • Есть возможность расширения функциональности с помощью плагинов. 

  • У платформы открытый исходный код – это значит, что если что-то там работает не так, либо нужно что-то поправить в дизайне, в интерфейсе, то можно попробовать сделать это самостоятельно. Если эта функциональность будет востребована, то можно отправить пулл-реквест в основной проект SonarQube.

  • И последнее, но не менее важное – SonarQube можно развернуть у себя на сервере, внутри.

В итоге получается, что мы можем развернуть у себя SonarQube и провести анализ проектов 1С, ничего не покупая из платного программного обеспечения. Только обеспечить сервер под развертку, арендовать его или купить.

 

Первый анализ в SonarQube

 

 

Что же мы увидели после первого анализа в коде проекта?

Конечно же, кучу ошибок, которые сначала кажутся необъятными. И что же с ними делать?

Ответ – ничего. Мы для себя решили, что сначала работаем над новыми замечаниями. И только потом, когда будет время, когда бизнесу будет незатратно, начинаем работать над существующими – их анализировать и исправлять.

 

Обзор проектов в SonarQube

 

 

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

 

 

На слайде показана главная страница проекта. Из нее можно увидеть какие-то основные показатели, состояние прохождения порога качества и тренд изменения метрик проекта 1С – какие замечания, проблемы у нас появились в новом коде. Обо всех этих показателях я сейчас расскажу подробнее.

 

Замечания по проекту. Классификация ошибок в коде.

 

 

Проблемы в коде бывают следующие:

  • Ошибки (критические проблемы в коде). В новом коде желательно их сразу исправлять – не нужно их оставлять на потом.

  • Уязвимости – они так же критичны, как и ошибки. Они являются отражением проблем безопасности в коде. И с помощью них можно нанести непоправимый вред информационной базе.

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

  • Дублирование кода – менее критично, чем дефекты кода. Но также влияет на простоту доработки. По сути, является отражением меры копипаста в проекте.

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

  • он не канонически пишет ключевые слова;

  • переменные называет одним символом;

  • объявляет константу в цикле;

  • неправильно добавляет в массив;

  • а потом неправильно вызывает элемент массива. 

То есть, надо Барта постоянно контролировать, либо вообще увольнять.

 

 

Далее – в самом проекте можно посмотреть список замечаний по проекту. SonarQube предоставляет гибкий отбор по замечаниям. Мы у себя, в основном, пользуемся отборами:

  • по типу замечания;

  • по дате его создания – смотрим, какие у нас были замечания за период;

  • по назначенному ответственному – кто этим замечанием должен заниматься и занимается;

  • и по конкретному правилу.

 

 

Как в принципе замечание выглядит?

Из него можно понять:

  • местоположение – модуль, где это замечание сработало, строчка кода, на которой оно сработало;

  • суть самого замечания – его заголовок (в данном случае «Отсутствует код в блоке «Исключение»);

  • тип;

  • статус;

  • дату создания;

  • кто ответственный за это замечание (кому оно назначено);

  • можно проставить теги, если они ведутся. В данном случае, если по тегу классифицируются какие-то проблемы, можно, допустим, написать, что это – Bad Practice. 

 

 

В контексте кода замечание выглядит так, как на слайде.

Мы видим блок «Попытка...Исключение». Видим, что блок исключения пустой. В данном случае это идеальный код, который всегда выполняется, и о проблемах с ним мы узнаем, только когда уже «припечет». В данном случае нужно либо писать сообщение что что-то пошло не так в журнал регистрации, либо выкидывать сообщения в пользовательский режим, либо вообще выкинуть исключение выше и прекратить выполнение алгоритма – не нужен нам такой код.

 

Профили качества

 

 

В SonarQube есть определенные сущности. Первая сущность называется профиль качества. Они нужны, чтобы группировать правила проверки и делать какие-то конкретные настройки по этим правилам. Для себя у нас создано два профиля качества:

  • общий профиль для проектов 1С в целом;

  • профиль конкретно под OneScript.

 

Пороги качества

 

 

Еще одна вещь в SonarQube – это пороги качества. Они нужны, чтобы установить границы уведомления о непрохождении порогов качества по каким-то выбранным критериям. Для одного из наших проектов на команду 5-8 человек были установлены следующие условия порога – мы за период 21 день не должны превышать:

  • больше 25 ошибок;

  • больше 300 замечаний;

  • больше 10% дублирования в коде;

  • и не больше нуля уязвимостей. 

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

 

Некоторые диагностики. Магические числа

 

 

Кто в зале знает, что такое магические числа? Это такие числа, про которые в коде нельзя однозначно сразу понять, что они означают. В качестве примера на экране показан кусок кода, в котором у нас проверяется какое-то условие, связанное, видимо, с датами. И при выполнении этого условия будет вызван какой-то метод. 

А что такое 7*60*60? Или 55*60? С первого взгляда это же не понятно? А когда опускаешься до контекста, то начинаешь понимать. Первое – это 7 часов в секундах. А второе – 55 минут в секундах. Это и называется магическими числами. 

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

У правила есть исключения, на которые эта диагностика не реагирует – это 0, 1, -1 и 86400 (1 день в секундах). 

 

 

Следующее правило – параметры при объявлении структуры. В упрощенном виде это правило гласит: «Не рекомендуется объявлять структуры с параметрами в параметрах других структур». 

Попробуйте прочитать код на экране (причем сначала это все еще и было записано в одной строчке – я для упрощения немного сузил). 

Это – плохочитаемый и плохоподдерживаемый код. При любом изменении в параметрах доработка такого кода почти всегда чревата ошибками. 

Правильно все структуры разбить на отдельные переменные. И множество параметров добавлять через «Вставить».

Как сказал один программист: «У меня с таким кодом вообще никогда проблем не было, я не первый день на родео и это далеко не первое мое родео». А нам такого родео не надо. С этим кодом можно обрести очень много проблем – что в разработке, что в продакшене.

 

Рассылка на почту

 

 

Перейдем снова к SonarQube – вот так выглядит уведомление, которое он присылает на почту. В данном случае, по уведомлению можно понять:

  • что это за проект, его версию;

  • что в данном случае случилось – появилось какое-то новое замечание 

  • и быструю ссылку, чтобы перейти к этому замечанию в веб-интерфейсе. 

Вообще у SonarQube есть несколько шаблонов рассылок. 

  • Одну вы видите на экране – это уведомление о новых замечаниях и изменении статуса предыдущих, уже существующих.

  • И вторая – это уведомление о непрохождении порога качества (либо прохождении).

 

Результат

Хочу подвести промежуточные итоги. Что мы получили после внедрения такого контроля?

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

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

 

Где взять диагностики кода?

 

 

В ходе использования платформы SonarQube у нас возникла необходимость внедрить больше правил. На основе анализа существующих решений были выявлены следующие источники – это:

  • 1С:АПК;

  • Проект BSL Language Server;

  • 1C:EDT, о которой я сейчас расскажу.

 

EDT

 

 

1С:EDT – это такой новый конфигуратор 1С. Он разрабатывается на базе IDE Eclipse. С помощью утилиты ring можно выгрузить список замечаний в произвольный формат csv. На борту имеется примерно 87 диагностик, которые частично пересекаются с основным плагином для SonarQube. Этот результат можно сконвертировать в понятный для SonarQube формат – generic issue с помощью проекта с GitHub, который называется edt-export (https://github.com/Stepa86/edt-export-bugs).

 

1С:АПК

 

 

Следующий источник – это 1С:АПК. Его разработала компания ИжТиСи в 2009 году. Решение позволяет в автоматическом режиме проверять конфигурации на соответствие стандартам разработки 1С и 1С:Совместимо.

В 1С:АПК есть настройка проверяемых требований. Мы у себя проверяем группу требований – это:

  • платформенные проверки конфигурации;

  • контроль разработки управляемых интерфейсов;

  • особенности кросс-платформенной разработки – мы используем решения не только на Windows, но и на Linux, поэтому нам важно проверять эти моменты;

  • также обработка и модификация данных – управляемые блокировки, использование транзакций и т.п.;

  • и последнее – это оформление модулей. В них входит структура модулей, описание процедур и функций и т.п.

 

 

Вот так у нас в SonarQube выглядят замечания, выгруженные из 1С:АПК. Для выгрузки замечаний из 1С:АПК в понятном SonarQube формате generic issue используется проект acc-export (https://github.com/otymko/acc-export).

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

Также можно выгрузить из 1С:АПК описание правил проверок в формате json и загрузить их в SonarQube. И, не открывая 1С:АПК, видеть описание проблем со ссылками на стандарты в ИТС. 

По каждому из правил можно предварительно оценить объем технического долга – сколько времени потребуется на исправление, и после выгрузки замечаний из 1С:АПК в SonarQube все это посчитать.

 

BSL Language Server

 

 

И последний проект – это BSL Language Server. Проверки для бесплатного плагина, который мы использовали в SonarQube, берутся из этого проекта.

Это – проект реализации Language Server Protocol для языка 1С. Чтобы увеличить количество диагностик в этом проекте, нужно участвовать в его развитии, писать на Java, на Kotlin. Понятно, что не каждая команда это себе может позволить, но, в принципе, какие-то базовые проверки пишутся не так сложно. 

На экране – немного кода Java. Что из него можно понять? 

  • у нас есть какое-то описание диагностики – ее тип, важность, время на исправление;

  • и есть какой-то класс с переопределенным методом, который посещает список параметров метода visitParamList. 

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

 

Изменение показателей проектов

 

 

Подведу финальный итог. Что же нам удалось добиться всем этим внедрением?

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

  • Разработчики теперь могут сами смотреть свои замечания и прорабатывать критические ошибки до внедрения в продакшен.

  • Появилась самообучаемость у младших разработчиков – их стиль кода и качество написания кода улучшились без какого-то особого вмешательства ведущего разработчика. 

  • Также с помощью SonarQube где-то на 20% быстрее стал ревью кода. 

  • Теперь мы можем смотреть динамику по проектам и использовать эту информацию в каких-то управленческих решениях. 

  • Итого, в краткосрочной перспективе, за 2-3 месяца нам удалось добиться прекращения увеличения замечаний по проектам, и начать работу над существующими.

 

 

Я хочу показать вам пару графиков – показателей одного из проектов.

Первый график – у нас анализ проводился с апреля по сентябрь 2019 года. На графике мы видим, сколько у нас в проекте было дублирующихся участков с копипастом. Начали мы примерно с 18 тысяч, сейчас примерно 7 тысяч. За это время нам удалось добиться уменьшения дублирования кода в 2 раза, и это очень хорошо. Уменьшили копипаст – проект стал более качественным.

 

 

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

 

Что у нас в планах?

 

 

Мы собираемся развивать эту тему дальше:

  • внедрить большее количество диагностик – то есть, участвовать в развитии проекта BSL Language Server;

  • довнедрить SonarQube в оставшихся проектах – их осталось немного;

  • разработать регламент, по которому бы Sonar внедрялся сразу в новые проекты;

  • и собираемся автоматизировать CodeReview с помощью связки SonarQube + GitLab + Cruisible. 

 

Полезные ссылки

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

Надеюсь, кому-то это покажется полезным.

 

Вопросы

  • Сколько человек у тебя сейчас работает и смотрит SonarQube и сколько всего проектов?

  • У нас сейчас работает 11 человек – в этом направлении движется. Проектов (разных конфигураций) у нас тоже 11. С дублирующими конфигурациями по разным направлениям у нас проектов около 15.

  • Ты особое внимание уделил слайду с дублирующимися участками. Почему для вас это было проблемой?

  • Конфигурация, на которой мы сейчас ведем основной учет – у нас внедрялась очень давно, 12 лет назад, может, даже больше. И там было очень много легаси-кода. Соответственно, там было очень много копипаста. Этот показатель на слайде показывает не просто количество дублирующихся строк кода, он показывает количество дублирующихся участков. То есть, есть функции, которые в разных модулях дублируются. И мы их потихоньку, с помощью SonarQube начали отслеживать и выпиливать. И новые отслеживать.

  • Почему потребовалось избавляться от этих дублей, из-за них возникали какие-то ошибки?

  • Просто получается, что у нас, допустим, есть метод генерации штрихкода, который вызывается в пяти разных местах. Если мы дорабатываем один метод – это хорошо. Но есть и другие вызовы такого же точно метода из других мест, и получается, что нам нужно доработать все эти места. А мы можем еще и забыть их доработать – мы не идеальны. Поэтому лучше уменьшить копипаст, чтобы какая-то конкретная функциональность была в определенных модулях, в определенных методах, и нигде ничего не дублировалась. Это избыточно.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Когда понадобился новый оператор

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда понадобился новый оператор, но его нет в синтакс-помощнике, что делать?

18.03.2024    1162    ZhokhovM    2    

4

Когда разработчик платформы не добавил проверку препроцессоров

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда разработчик платформы решил пойти на кухню за кофе, а проверку препроцессоров не добавил, и вот тут-то и началось: "Что, опять все сломалось? Ну и кофе же я забыл сделать!".😅

18.03.2024    2695    ZhokhovM    4    

9

Реструктуризация - бесконечная история

Рефакторинг и качество кода Платформа 1С v8.3 Бесплатно (free)

При разработке программ требуемый функционал ставят на первое место, но есть еще и архитектура программы. На горизонте 5-10 лет она становится важнее функционала, который должен работать при масштабировании и росте данных. Реструктуризация 5 терабайтной базы 1С 8.2 в формат 1С 8.3, складывает весь пазл архитектурных просчетов, которые сделали ради функционала. Как это исправить? - для разработки правильной архитектуры, нужно всего лишь сместить фокус с функционала и подумать о «вечном».

29.09.2023    1910    1CUnlimited    15    

22

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 2

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Коротко о том, как я перестал быть создателем макаронного кода и непроходимых джунглей методов и модулей. Расскажу о том, что реально применяю на практике с примерами при разработке (а в основном доработке) в типовых конфигурациях 1С. Комментарии очень приветствуются.

27.09.2023    6972    Lemmonbri    136    

36

Чистый код. Мой взгляд на жизнь в макаронных джунглях. Часть 1

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Коротко о том, как я перестал быть создателем макаронного кода и непроходимых джунглей методов и модулей. Расскажу о том, что реально применяю на практике с примерами при разработке (а в основном доработке) в типовых конфигурациях 1С. Комментарии очень приветствуются.

19.09.2023    4353    Lemmonbri    16    

31

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Архитектура Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

Нашей компании часто приходится сталкиваться с обновлением конфигураций разной степени переписанности. Какие-то из них обновляются легко, какие-то — не очень. Расскажем о некоторых принципах модификации программы, которые помогут сделать последующий процесс обновления легче. Или тяжелее, если стараться их не соблюдать.

10.08.2023    9592    0    1c-izhtc    37    

21

Задача на ошибки и неоптимальности при проведении приходной накладной

Рефакторинг и качество кода Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Задачу эту дают на собеседованиях, видимо, те франчи, которые не в состоянии оценить человека по резюме и в ходе беседы. По идее задачи, подобные этой, должны давать начинающим студентам. Но дают всем подряд. Итак: мои 5 копеек. Критика приветствуется.

11.07.2023    2216    magic1s    32    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Vladimir Litvinenko 2869 12.03.20 10:48 Сейчас в теме
О! Какая отличная статья. Интересно продолжение.

Получилось ли поставить Crucible в связке с Gitlab? Дал ли он нужный эффект без Fisheye?
Используется он сейчас с Jira или с другой системой учета задач? Если не с Jira, то как обстоят дела с интеграцией с системой учета задач?
Как выполняется ревью, если по задаче куча закладок в хранилище?
Какие задачи ставятся перед код-ревью в целом, с учетом наличия автоматических анализаторов? (ведь есть мнение, что они вообще заменяют проверки человеком).
3. &rew 49 12.03.20 12:03 Сейчас в теме
(1)
Получилось ли поставить Crucible в связке с Gitlab? Дал ли он нужный эффект без Fisheye?

Как будто РБК посмотрел)
Rabot; wowik; +2 Ответить
4. Vladimir Litvinenko 2869 12.03.20 12:10 Сейчас в теме
(3) Не очень понял при чём тут РБК? Автор в публикации озвучил планы применить Crucible в связке с Sonar и Gitlab и возможно уже попробовал такую связку (это доклад с прошлогоднего выступления). По моей практике этот инструмент даёт хороший эффект только в связке с Fisheye, так как только в этом случае можно удобно смотреть историю изменений по одной задаче, если по ней было много закладок в хранилище. В ином случае казалось проще просто каждый коммит в отдельности смотреть, что по идее уже сам по себе Gitlab позволяет.

Интересуюсь можно ли получить эффект от инструмента, если его только с Gitlab срастить, так как сам не пробовал. Плюс вопросы по ревью.
7. olegtymko 889 13.03.20 04:07 Сейчас в теме
(1)
Получилось ли поставить Crucible в связке с Gitlab?


Crucible пока не воспользовались, т.к. сначала нужно поменять кардинально процесс разработке (все еще впереди). Для учета задач у нас используется 1С: ДО (переход на другую систему учета задач рассматривается).

(1)
Как выполняется ревью, если по задаче куча закладок в хранилище?


Пока только руками, по сопроводительному письму разработчика.

(1)
Какие задачи ставятся перед код-ревью в целом, с учетом наличия автоматических анализаторов?


Стат. анализ полностью не сможет заменить человека при проверке кода, часто его можно обойти разными хитрыми фокусами и оставить "запашок".
Vladimir Litvinenko; +1 Ответить
8. Vladimir Litvinenko 2869 13.03.20 11:50 Сейчас в теме
(7) Олег, спасибо за ответы! Надеюсь у Вас ещё будут публикации на эту тему.
2. &rew 49 12.03.20 11:59 Сейчас в теме
главное при написании хорошего кода – это не писать его сложно, а писать его настолько просто, чтобы программист, не погруженный в контекст, мог понять, что к чему.

Надо в 1С написать, а то непонятно, зачем под всегда возвращающую ЛОЖЬ функцию городить такой огород в КА2.4
Функция УказаниеНаправленияДеятельностиОбязательно(ХозяйственнаяОперация) Экспорт
	
	Если НЕ ПолучитьФункциональнуюОпцию("ФормироватьФинансовыйРезультат") Тогда
		Возврат Ложь;
	КонецЕсли;
	
	ЭтоДоходнаяОперация 		= ХозяйственнаяОперацияОбразуетДоход(ХозяйственнаяОперация);
	ЭтоОперацияОбразующаяАктив 	= ХозяйственнаяОперацияОбразуетАктив(ХозяйственнаяОперация);
	ОбязательныйУчетДоходов 	= Ложь;
	ОбязательныйУчетЗатрат		= Ложь;
	
	Если ЭтоДоходнаяОперация И ОбязательныйУчетДоходов Тогда
		Возврат Истина;
	ИначеЕсли ЭтоОперацияОбразующаяАктив И ОбязательныйУчетЗатрат Тогда
		Возврат Истина;
	КонецЕсли;
	
	Возврат Ложь;
	
КонецФункции
Показать
5. ImHunter 312 12.03.20 13:24 Сейчас в теме
(2) Видимо, быстро пофиксили присвоение переменных ОбязательныйУчет* (сделали Ложь вместо вызова какой-то ф-ии), а код не отрефакторили.
6. &rew 49 12.03.20 13:34 Сейчас в теме
(5)Вот интересно, пользуются ли они своим продуктом 1С Автоматическая проверка конфигураций.
9. check2 354 13.03.20 20:32 Сейчас в теме
Коллега, GitLab и SonarQube дружат даже в CE edition GL (я ни разу не настраивал эту связку, но задумываюсь). Подскажите, и это не сарказм, зачем нужен Jenkins?
10. php5 25 02.12.20 18:55 Сейчас в теме
Интересно, что покажет проверка типовой конфигурации и сколько выявит ошибок 😄
siamagic; +1 Ответить
11. axelerleo 339 07.12.22 10:28 Сейчас в теме
Коллеги, какие есть варианты "борьбы" с показателями дублирования кода, если проект - типовая конфигурация? Более 1,3 млн дублированных строк, 17% дублирования. Что можно предпринять?
Типовые модули мы явно не будем рефакторить, но и исключать их из анализа нельзя - на случай, если мы туда уже сами добавим какой-то код.
Можно ли дублирование отключить для определенного автора(коммиты от вендора отсечь, например)?
12. siamagic 15.03.23 11:03 Сейчас в теме
он не канонически пишет ключевые слова;

переменные называет одним символом;

объявляет константу в цикле;

неправильно добавляет в массив;

а потом неправильно вызывает элемент массива.


Символом исконно обозначается счетчик

Как правильно добавлять в массив и вызывать элемент массива, почему?
Оставьте свое сообщение