SonarQube. А надо ли?

10.03.25

Разработка - Тестирование QA

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

Давайте "скормим"  на проверку Сонару "коричневый пахучий" код?

 

 

Замечаний даже прилично выдал, целых 5:

 

 

Отработаем все замечания - результат:

 

 

Код, конечно, гораздо качественнее стал...

Вот сижу теперь и размышляю: а обеспечила ли я, как технический архитектор, настоящее качество кода, внедрив этот инструмент? Или просто завернула это самое "оно" в "красивый блестящий фантик"?

P.S. Эта заметка - "шутка юмора", призывающая немного поубавить градус "пафоса и пиетета" вокруг "модных красивых игрушек". И задуматься о том, где у нас в коде на самом деле, постоянно, по всей стране, на протяжении многих лет, "сбоит" и почему.

SonarQube - отличный бесплатный инструмент. Обязательно внедряйте.

И будут у Вас комментарии в коде красивые-красивые! С пробельчиками)))

 

P.S.2 Неужели "экстерьер" и в коде важнее "внутреннего содержания"?

 

P.S.3  Кто не понял, эта заметка вообще не про СонарКуб (ему просто незаслуженно досталось, поскольку он ко мне первым в руки попал). Эта заметка про то, что в профессиональном сообществе идет крайне настойчивый призыв к внедрению процессов по управлению качеством кода, без четкого объяснения, что такое качество кода, и в чем его "экономическая выгода". Вместо призыва "основы подкачать", хотя большая часть разработчиков 1С до сих пор не знает, как правильно запросы для СКД писать, не понимает, как устроен регистр накопления, бесконечно гоняет контекст формы между клиентом и сервером, и ДО СИХ ПОР получает через точку значения реквизитов от ссылки.

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

 

Вступайте в нашу телеграмм-группу Инфостарт

Архитекторы развлекаются Архитектурные заметки SonarQube разработчикам/архитекторам на заметку долой стереотипы пофилосовствуем?

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

DevOps и автоматизация разработки Мониторинг Тестирование QA Программист 1С:Предприятие 8 Бесплатно (free)

Платформа 1С давно вышла за рамки учетных систем. Сегодня это полноценная среда для создания сложных, высоконагруженных и распределенных приложений. А значит, и стек технологий современного разработчика кардинально изменился. Систематизируем весь инструментарий, который превращает 1С-программиста в инженера: от EDT и Git до автотестов на YAxUnit, контейнеризации приложений в Docker, мониторинга в Prometheus и организации шины данных на Kafka. Разберемся, зачем каждый инструмент нужен, как он вписывается в жизненный цикл разработки и с чего начать его внедрение.

25.08.2026    15189    mrXoxot    49    

65

HighLoad оптимизация Тестирование QA Программист 1С 8.3 Бесплатно (free)

Шесть внешних отчётов на боевой базе крупной сети переписали за неделю. По секундомеру ускорились четыре, в акт пошли три: у одного отчёта минус тринадцать процентов оказались выбросом нагрузки прода, а не эффектом кода. Поймал это чередующийся замер до/после в одном окне, обычные три прогона с метрикой "минимум" показывали ускорение уверенно. Дальше в тексте: почему построчная сверка выхода ломается ровно на тех правках, ради которых её заводят; из чего собирается повторяемый слепок результата и почему главную работу в нём делает нормализация, а хеш только сигнализация; где слепок не берётся вовсе и его заменяет по-колоночная сверка; чем проверять пересчёт итогов, чистку данных и операции с кластером. Отдельно - гипотеза, которую замер отклонил, и честный счёт, во что вся эта дисциплина обходится.

21.08.2026    807    nedomolkov.ivan    0    

0

Тестирование QA Программист Бесплатно (free)

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

17.08.2026    701    user2181343    0    

1

Тестирование QA Программист 1С 8.3 Россия Бесплатно (free)

Написать тест на 1С несложно. Дорого стоит привести базу в состояние, где прогон вообще стартует: семь шагов, каждый ломает запуск молча — без ошибки, без записи в журнале. И эту цену платит заново каждый новый человек на проекте. Разбираю молчаливый отказ окружения как класс проблем, показываю, почему его не закрывают ни документация, ни скрипт развёртывания, и предлагаю решение — фиксацию состояния в артефакте с машинно-проверяемым критерием приёмки. Подход проверен на сквозной задаче (первая задача экзамена «1С:Специалист по платформе» с юнит- и функциональными тестами), а затем перенесён на пул тестовых баз с типовыми конфигурациями. Отдельно — каталог симптомов и их настоящих причин, который пригодится независимо от инструментария.

13.08.2026    990    chagbig    1    

0

Тестирование QA Программист Бесплатно (free)

Разбираем, как в крупных компаниях регуляторные требования, постмортемы и внутренние ограничения постепенно превращаются в многоуровневую систему инструкций, в которой разработчику все сложнее понять, что и когда нужно проверить. Показываем opensource-сервис внешних проверок для GitLab, который автоматизирует часть этой бюрократии и сводит результат к понятному сигналу: зеленое – все в порядке, красное – нужно обратить внимание на конкретное требование. Объясняем, как такие проверки помогают «сдвинуть влево» контроль задач и снизить риск отказа во внедрении задачи в последний момент перед релизом. А заодно смотрим, может ли связка Autumn + «Вино» + немного разработческого энтузиазма превратить обязательные инструкции в инструмент, который команда сама захочет развивать.

12.08.2026    913    Golovanoff    2    

3

Поиск данных Тестирование QA Программист 1С 8.3 1С 8.5 Бесплатно (free)

Как мы пришли к Юнит-тестированию и почему стоит его использовать. Использование универсальных тестов для проверки работы IS MagicInput в вашей конфигурации.

16.07.2026    2090    Evg-Lylyk    2    

5

Тестирование QA Программист Бесплатно (free)

Tantor Postgres 18 - масштабный релиз СУБД, за которым стоят месяцы тестирования, сотни часов нагрузочных прогонов и десятки исправлений, о которых пользователь никогда не узнает просто потому, что они были найдены и устранены до выхода версии. Александр Симонов, руководитель направления развития 1С в "Тантор Лабс", рассказывает, как устроен процесс тестирования изнутри - почему одного эталонного прогона недостаточно, что делать, когда ванильный PostgreSQL 18 ломает собственные оптимизации, и как Tantor Postgres приближается к той планке, которую MS SQL Server держал годами.

07.07.2026    1514    Tantor    2    

6

Тестирование QA Программист Бесплатно (free)

Юнит-тестирование в 1С – тема, о которой много говорят, но внедряют далеко не везде: для одних это признак зрелой разработки, для других – избыточная формальность или лишняя трата времени. Разбираем, почему классическая пирамида тестирования в 1С часто оказывается перевернутой, какие ограничения накладывает платформа и почему юнит-тесты в реальных проектах нередко смешиваются с интеграционными. Показываем, где юнит-тесты действительно помогают ускорить разработку, упростить проверку логики и повысить качество кода, а где их применение превращается в хрупкую и дорогую поддержку. Отдельно разбираем типичные ошибки: зависимость тестов от данных и окружения, избыточное мокирование, тестирование платформы вместо бизнес-логики и отсутствие негативных кейсов.

29.06.2026    3149    alexandr_yang    6    

12