(3) ну, например, чтобы:
- не настраивать ответственных по объектам метаданных в АПК: SonarQube сам определит ответственного за косячный код по git blame;
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
- видеть ошибки АПК в контексте окружающего кода, а не только модуль и номер строки;
- ускорить отображение отчётов;
- получать постоянные ссылки на ошибки, чтобы взять их на контроль и добиться исправления.
5.
Vladimir Litvinenko
184407.07.19 23:46 Сейчас в теме
(4) Вы можете делать коммиты, связанные с обновлением типовых конфигураций (обновлением БСП или переходом на новую версию типовой конфигурации) от имени специально выделенного пользователя. Для этого достаточно перед коммитом указать в качестве e-mail автора служебный или свой второй e-mail. Тогда изменения типовой конфигурации привяжутся не к тем пользователям, под которым ведется регулярная разработка.
В этом случае разработчики получат возможность видеть и исправлять только свои ошибки. В общем случае вы будете видеть и ошибки типовой, но в этом нет ничего плохого. Их всегда можно будет отбросить на основании авторства изменений.
Если вы пользуетесь АПК, то ситуация будет аналогична: если Вы дорабатываете типовой модуль и хотите его проверить после доработки, то в результаты его проверки попадет и типовой код и Ваш. АПК позволяет фильтровать объекты конфигурации, подлежащие проверке, а не части модулей. При использовании возможностей git как раз появляется возможность проверять только внесенные в модуль изменения в привязке к авторам.
(12) На скриншоте тестовый проект, где ~800 ошибок, был проверен только в рамках статьи.
Во вложении метрики самописного проекта не на БСП, над который сейчас ведутся работы по улучшению качества кода (этот же скриншот есть в статье).
Если смотреть тренд количества ошибок, дублирования кода - то их количество со временем уменьшается.
(41) Так оно наверняка у вас не работает, и вы уже тратите ресурсы на поиск этой ошибки. Если это в "не используемом" функционале, то конечно фиг бы с ней. Это если про вендорный код. А в своем в принципе сразу видите "ой тут наверное что то не так" и исправляете.
(37) В 1С в некоторых отделах, на некоторых продуктах работают весьма отзывчивые люди. Присланный им на партнерке или в саппорт репорт внезапно не отфутболивается, баг или недоработка берется в работу и исправляется, а сами сотрудники тебе благодарны за помощь.
Такое случается не везде, но если случается, то вселяет веру в людей и надежду что наше дело - "правое".
(46) Ооо нет, что вы) сонаркуб это чудесно. Просто где бы взять время на настройку и понимание всей этой инфраструктуры? Если куча свободного времени и осталось только причесать код по указке сонаркуба - тогда я вам завидую :) вы молодец
(57)
Я ни на что не намекаю, но очень часто бывает так, что свободного времени нет именно потому, что код - говно, и на поддержку его уходит всё свободное время :)
(3)автоматизированно в контуре ci проводить анализ состояния системы и с помощью sonarqube видеть общий тренд изменения качества решений. Так же, на мой взгляд, одна из самых главных "плюшек" сонара - привязка результатов диагностик к пользователям через git blame. Для меня ещё полезным показалось дублирование кода - этого соответственно нет в АПК.
(3) ну, например, чтобы:
- не настраивать ответственных по объектам метаданных в АПК: SonarQube сам определит ответственного за косячный код по git blame;
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
- видеть ошибки АПК в контексте окружающего кода, а не только модуль и номер строки;
- ускорить отображение отчётов;
- получать постоянные ссылки на ошибки, чтобы взять их на контроль и добиться исправления.
- разделить ошибки на legacy и привнесённые в новом коде, старый код не трогать, а сосредоточиться на исправлении новых косяков;
В последних версиях АПК появился режим "поместить все ошибки в исключения" как раз для первоначального занесения всех ошибок в исключения в старом коде.
В последних версиях АПК появился режим "поместить все ошибки в исключения" как раз для первоначального занесения всех ошибок в исключения в старом коде.
Этот сценарий я рассматриваю как потенциально опасный, т.к. маскирует потенциальные ошибки.
Пример:у меня эпизодически проявляется ошибка "Операция не может быть выполнена из-за несоответствия версии или отсутствия записи базы данных (возможно, запись была изменена или удалена)!"
Я открываю SonarQube, ставлю фильтр на каталог по имени модуля и вижу там ошибку "Отсутствует исключительная управляемая блокировка на записываемые (удаляемые) данные." - эта ошибка унаследованная, привнесена была год назад, но благодаря связке АПК+SonarQube я могу определить причину и исправить ошибку.
Так что, если поместить все старые ошибки в исключения, возможности оперативно диагностировать источник ошибки у меня не будет.
На практике или дописываю типовую конфу, или делаю свою на базе БСП. В обоих случаях собственного кода в общем объеме не так и много. Можно ли анализировать только отличия от типовой? Зачем мне знать качество кода других программистов, раз на них никак не влияю...
5.
Vladimir Litvinenko
184407.07.19 23:46 Сейчас в теме
(4) Вы можете делать коммиты, связанные с обновлением типовых конфигураций (обновлением БСП или переходом на новую версию типовой конфигурации) от имени специально выделенного пользователя. Для этого достаточно перед коммитом указать в качестве e-mail автора служебный или свой второй e-mail. Тогда изменения типовой конфигурации привяжутся не к тем пользователям, под которым ведется регулярная разработка.
В этом случае разработчики получат возможность видеть и исправлять только свои ошибки. В общем случае вы будете видеть и ошибки типовой, но в этом нет ничего плохого. Их всегда можно будет отбросить на основании авторства изменений.
Если вы пользуетесь АПК, то ситуация будет аналогична: если Вы дорабатываете типовой модуль и хотите его проверить после доработки, то в результаты его проверки попадет и типовой код и Ваш. АПК позволяет фильтровать объекты конфигурации, подлежащие проверке, а не части модулей. При использовании возможностей git как раз появляется возможность проверять только внесенные в модуль изменения в привязке к авторам.
(9) Итак, получилось развернуть, но обо всем по порядку:
До этого разворачивал SonarQube 7.7 на стандартном порте 9000 - особо не успел разобраться, но он работал.
Затем, после вашей статьи, решил обновиться до 7.9. И весь вчерашний день решал головоломку, почему он то запускается, то падает.
Оказалось дело в jdk 11, странно что он без нее работал (но как-то криво)
Так что про jdk не забываем :)
Из статьи не понятен был момент - нужно ли создавать проект с ключем в SonarQube или он автоматом сам создастся?
Я создал проект, и в файле настроек указал параметры проекта.
И я в итоге сделал вот так
.../sonar-scanner.bat -D"project.settings=../sonar-project.properties"
а дальше в sonar-project.properties указал путь к проекту:
***
sonar.projectBaseDir=С:/myrepos/myprjkt
***
Кстати не забываем что слэш должен быть в файлике настроек именно "/" - а то пару раз косякнул с этим
И мое микро замечание - в секции примера слэш хорошо бы тоже одного направления сделать
"Без токена:
(91) по поводу ключей и каталогов - мною специально был заготовлен шаблон проекта и если следовать указаниям, не нужно будет прописывать отдельно путь к настройкам сонар проекта и к рабочему каталогу.
(93)
Протестировал на маленькой базе - все нормально отработало.
Запустил аналогично на большой базе - 4 часа скрипт работал, и самое что странное ругнулся в самом конце
ERROR Caused by: GC overhead limit exceded
что еще странно что процент выполнения проверки файлов тормозиться по экспоненте. И последние 10 файлов проверялись 1 час.
Попробовал дописать исключение в файл настроек конкретного проекта -
sonar.exclusions= .... (кстати было бы круто если бы статье был пример шаблонных исключений)
Но ничего не поменялось.
Пишут в интернетах про SONAR_SCANER_OPTS - но я не пойму, это переменная среды? Если нет, то где ее надо указать? Где можно посмотреть сколько памяти используется фактически?
Мне не критично если анализ будет хоть целый день идти, его каждый день запускать смысла нет.
(101) Сканеру не хватило памяти. У меня такое было при анализе УХи. Переварить регл. отчетность помогло только выдача сканеру 20 гигов оперативы. Вот пример батника
Да в статье описано, но у меня "Parsing files" не застряло где-то, а прошло все 100% и дальше стопорнулось.
SONAR_SCANNER_OPTS - по идее я эту настройку ранее уже выставил, просто связи с реальностью пока не увидел, возможно где-то очепятался, буду тестировать :)
"Предупреждён — значит вооружён". Теперь мы понимаем что у нас есть 2 тыс. критических проблем и 44 уязвимости. Их нужно устранять, чтобы сделать решение более стабильным. Так же нужно учитывать, что большая часть кода - это код на поддержке. Его нужно исключить. Для этого можно использовать проект https://github.com/Stepa86/edt-export-bugs. Далее используя анализ на продолжительном периоде, можно отслеживать новые ошибки / дефекты с помощью отбора по дате создания замечания. (см. приложенный файл)
(11) gitsync
На вашем проекте, судя по скриншотам, >800 ошибок и 23 тыс. дефектов?
Покажите, пожалуйста, тренд количества ошибок или что-нибудь отображающее профит.
Очень уж любопытно, продвинулись ли Вы куда-нибудь дальше "понимания".
(12) На скриншоте тестовый проект, где ~800 ошибок, был проверен только в рамках статьи.
Во вложении метрики самописного проекта не на БСП, над который сейчас ведутся работы по улучшению качества кода (этот же скриншот есть в статье).
Если смотреть тренд количества ошибок, дублирования кода - то их количество со временем уменьшается.
Скажите пожалуйста, получается то есть, если проект на обычных формах - каждый раз, перед выгрузкой файлов конфигурации в project/src (ну или перед выгрузкой этих же файлов git) - их нужно разобрать? И код из ссылки это все корректно делает?
За статью - спасибо, очень большая и ценная работа проделана
(35) Да, придется их разобрать. Иначе все обычные формы будут в файлах bin, и проверки bsl ls их не увидят. Так же АПК не увидит файлов, на которые можно повешать замечания.
Этим скриптом пользуюсь я сам. Тоже самое можно с помощью gitsync сделать.
(11) А какую версию v8unpack используете? Пытаюсь парсить обычные формы при помощи вашего скрипта получаю исключение:
"Внешнее исключение System.Reflection.TargetInvocationException): Адресат вызова создал исключение."
(21) Я там скрин наверху оставил, с результатом "минимального набора". На текущий момент мне известно 4ре анализатора, их результаты можно импортить в сонар. На 3 есть отсылы в статье.
(25) Пропустил диспут в телеге, но вот с термина "игрушка" приорал знатно. Особенно когда в курсе цен на эту игрушку и затрат, которые несутся без неё.
(174) Именно. Я буквально из под палки заставляю коллег код-ревью делать. И им каждый раз "некогда", несмотря на 6-7 значные суммы убытков из-за простоя базы дольше 15 минут. А с сонаром хотя бы часть ошибок не окажется в продакшене. Соответственно меньше претензий к нашему отделу со стороны руководства.
Коллеги, знаю, что бесплатный сонар позволяет анализировать одну ветку. В примере из статьи - это master. По вот этому workflow содержимое ветки master - это то, что находится в боевой системе. Получается, что контроль качества выполняется после публикации изменений? Или я что-то неправильно понял? Пробуем использовать инструменты контроля качества. И пока не получается запустить инструмент так, чтобы он проверял изменения каждого разработчика перед публикацией.
(26) если работаете в EDT, то можно доустановить плагин от Александра Капралова, который будет показывать диагностики из BSL LS прямо в EDT.
А так да, выше дали ссылку на комьюнити бранч-плагин, лично проверял его работу на 4 серверах от 7.4 до 7.8.
Недавно вышел релиз плагина под свежий LST релиз SonarQube, конкретно его я еще не проверял, но в комментариях пишут, что работает.
(34) радует, что не все комьюнити с менталитетом кодера "сказали-делаю, а вот это все остальное - для меня сложно" чем прогрессивнее будет комьюнити, тем лучше со временем станут условия для 1с разработчиков не как добывателей денег, а как специалистов.
(47) это проверка из разряда "защитного программирования". Нужно на 100% быть уверенным, что это не "иначе" продолбали, а просто предварительную инициализацию сделали. Плюс не во всех ветках бывает такой простой инкремент, где-то могут вызываться функции с побочным эффектом.
Уверены, что в данном случае все в порядке? ставьте на конкретное срабатывание статус won't fix.
Уверены, что всегда все ок или вас эта проверка раздражает - выключайте проверку в настройках "Quality Profile" или в конфигурационном файле BSL Language Server (в зависимости от режима запуска)
(50)
Копипаста - звучит как что-то плохое) Я бы в данном контексте его не использовал. Потому что у меня нет Иначе, а без него мне не нужен Инкремент, он в конце ошибку даст. Потому что формально в вашем примере добавлено одно ненужное действие, которое может выполняться, например, в цикле, например, миллион раз - и вот уже у нас миллион ненужных действий. Если же Инкремент вынести за Если, то тогда у нас миллион ненужных присваиваний переменных.
(55) Все зависит от цены. Да, и тут вы тоже правы, миллион действий что-то стоит. Дальше обычно идет болтовня о компромиссе между производительностью и поддерживаемостью.
1. 836мс
2. 984мс
(47) Холиварная тема. У меня в коде больше таких условий:
КолвоОчков = 10;
Если Ничья Тогда
КолвоОчков = КолвоОчков + 1;
ИначеЕсли Победа Тогда
КолвоОчков = КолвоОчков + 3;
Иначе
ВызватьИсключение("Никогда такого не было и вот опять");
КонецЕсли;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков);
(56) Вот Олег попался в ловушку отсутствия какого-то указания на то, что при проигрыше КоличествоОчков не увеличивается и случайно все сломал. Это и называется поддерживаемость =)
(60)
Тут я могу только начать реальный холивар, заявив, что это не функция кода - объяснять бизнес-логику, что для этого должно быть ТЗ, документация и комментарии:
КолвоОчков = 10;
Если Ничья Тогда
КолвоОчков = КолвоОчков + 1;
ИначеЕсли Победа Тогда
КолвоОчков = КолвоОчков + 3;
// проигрыш - кол-во не меняется,
// никаких других ситуаций не бывает
КонецЕсли;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков);
Показать
Причём, не отменяя нужность документации, думаю, важнее всего как раз такое писать в комментарии, потому что он ближе всего к программисту.
(64) Вот именно в Иначе и нужно вставить этот комментарий, чтоб всем остальным было очевидно, что здесь не продолбали вариант с проигрышем. А еще лучше, чтоб волшебные цифры 0, 1 и 3 были инкапсулированы
Если Ничья Тогда
выигрыш = КоличествоОчковПриНичьей();
ИначеЕсли Победа Тогда
выигрыш = КоличествоОчковПриПобеде();
Иначе
выигрыш = КоличествоОчковПриПоражении();
КонецЕсли;
КолвоОчков = КолвоОчков + выигрыш;
ЗаписатьВТурнирнуюТаблицу(КолвоОчков);
(65)
Это был очень условный пример, показывающий, что Иначе пригождается не всегда) Понятное дело, что хардкодинг - это Г-код, но смысл примера был не в этом.
(71) Этот пример в итоге показал, что затраты на Иначе окупились бы. Эта проверка на тех. долг. А тех. долг влияет на сопровождаемость - то есть насколько легко этот код смогут доработать другие программисты. Пример Олега показал, что именно в этом месте этот тех.долг выстрелил в ногу, а значит сонар очень даже правильно диагностировал проблему.
На моем реальном боевом проекте я тож сперва был скептически настроен к этой проверке. Психанул и везде, где в Иначе не должны заходить никогда расставил вызов исключений. И я очень удивился, когда у меня тесты отвалились.
Этот пример в итоге показал, что затраты на Иначе окупились бы.
Каким образом? Вы показали будущему программисту логику через Иначе (т.е. ещё одну команду и даже вызов функции), я - комментарием. Информация та же, вызовов меньше.
И я очень удивился, когда у меня тесты отвалились.
Возможно, нужно внимательнее подходить к разработке. Если вы говорите, что в Иначе не должно заходить никогда, а у вас исключения полезли, то тем, что вы сделаете пустое Иначе, вы проблему не решите.
(74)
> Вы показали будущему программисту логику через Иначе
И комментарий и логика используют ветку Иначе и поэтому стало понятнее и сложнее совершить ошибку. Можно обойтись и комментарием. Главный посыл в том, что ветка Иначе тут нужна.
> Возможно, нужно внимательнее подходить к разработке.
Да-да, нужно. Нужно писать без ошибок. У меня не получается. Поэтому я использую всякие вспомогательные костыли, типа статистического анализа кода, код-ревью, тесты и прочую ненужную вещь, чтобы снизить количество ошибок. Исключение в блоке иначе, в который никогда не должны бы заходить работает значительно лучше, чем отсутствие такого блока в принципе, потому что мы посчитали, что сюда не должны бы зайти.
потому что мы посчитали, что сюда не должны бы зайти
Одно дело - посчитали, другое дело - уверены. В указанном мною высосанном из пальца примере, никаких других вариантов быть не может, соответственно, Иначе просто можно выкинуть. Выкидывать Иначе там, где я не знаю, зайдут туда или нет - я не предлагал)
И повторюсь - исключениями вы неправильную логику не почините. Исключения в Иначе могут быть полезны на этапе разработки, чтобы было понятно, что за данные идут и что делать. После понимания, исправления и т.п. эти Исключения, которые остались невызванными, нужно удалить, туда же можно удалить и Иначе, которые останутся пустыми.
Правила нужны для того, чтобы облегчать жизнь. Если правилам следуют просто формально, то это, видимо, неправильные или неправильно понятые правила. За добрый десяток постов мне так и не показали, где в моём абстрактном примере мне понадобится Иначе. А пихать его просто потому, что где-то кто-то сказал, что Иначе должно быть - не знаю почему, но не хочется)
(89) Не всем повезло с умением писать сразу код без ошибок, который в последствии не требует сопровождения и доработок.
Исключения удалять как раз нельзя. Они нужны не для того, чтобы падало при разработке, а для того, чтобы падало, когда кто-нить другой в каком-нить другом месте сделал некорректную доработку.
Чем проще система, чем меньше программистов участвует в разработке и чем меньше ущерб от ошибок в ней - тем меньше можно заморачиватся с внутренним качеством.
(64)Нас же предупреждали, что это диагностика холиварная. На примерах разобрали, что придумана не из воздуха. В планах есть добавить настройку, что бы она срабатывала только на СелектКейсах.
Использовать ее на своих проектах или нет, решаете вы сами.
P.S. У некоторых диагностик есть параметры. Например, можно увеличить ограничение на длину строки (Стандарт глосит: 120. Имхо: 140).
(62) На данный момент не все, но в планах добавить. Ну и самое главное - это OpenSource проект. Можно создать issues c идеями / проблемами, можно самому доработать проект.
Добрый день. Словил ошибку
java.lang.IllegalArgumentException: Start pointer [line=3313, lineOffset=0] should be before end pointer [line=3313, lineOffset=0]
Перенос данных КА 1.1 / УПП 1.3 => БП 3.0 (перенос остатков, документов и справочников из "1С:Комплексная автоматизация 1.1" / УПП 1.3 в "1С:Бухгалтерия 3.0")