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

Публикация № 1175305

Методология - Рефакторинг и качество кода

При быстром росте функциональности проводить визуальный 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. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие

Специальные предложения

Избранное Подписка Сортировка: Древо
В этой теме еще нет сообщений.
Оставьте свое сообщение

См. также

Качество кода: слабое связывание и высокая сопряженность (Low coupling and High Cohesion)

Статья Программист Нет файла Бесплатно (free) Рефакторинг и качество кода

Поговорим о некоторых общепринятых подходах и принципах разработки кода.

10.02.2020    4157    ivanov660    90       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Стабильность превыше всего

Статья Программист Нет файла v8 Бесплатно (free) Рефакторинг и качество кода

Странная заметка о поддержании стабильности в условиях интенсивного изменения конфигурации.

07.11.2019    6333    YPermitin    40       

Оценка скорости кода. Сложность алгоритма

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Практика программирования Рефакторинг и качество кода

Эта тема одной из первых всплывает на собеседовании программистов языков вроде Java и C, но она почти неизвестна в "мире 1С". Поговорим о вычислительной сложности алгоритмов.

07.10.2019    2926    m-rv    10       

1C:Предприятие для программистов: Запросы и отчеты. Второй поток. Онлайн-интенсив с 17 марта по 16 апреля 2020 г. Промо

Данный онлайн-курс предусматривает углубленное изучение языка запросов и возможностей системы компоновки данных, которые понадобятся при разработке отчетов, работающих на платформе “1С:Предприятие” в рамках различных прикладных решений. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”, а также для опытных пользователей различных прикладных решений, которые используют в своей работе отчеты разного назначения.

6500 рублей

Конвейер проверки качества кода

Инструменты и обработки Программист Архив с данными v8 1cv8.cf Windows Абонемент ($m) Инструментарий разработчика Практика программирования Математика и алгоритмы

Jenkinsfile для выполнения проверки качества кода. Собирает информацию с АПК, EDT и BSL-LS. Сопоставляет ошибки с гит-репозиторием, выгруженным ГитКонвертором. Отправляет в Сонар.

3 стартмани

04.09.2019    11220    17    Stepa86    44       

Управление качеством кода

Статья Программист Руководитель проекта Нет файла v8 Бесплатно (free) Математика и алгоритмы Рефакторинг и качество кода

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    11536    Stepa86    33       

Базовый курс по управлению ИТ-проектами. Курс проходит с 26 февраля по 22 апреля 2020 года. Промо

Отличительная черта курса - органичное сочетание трех вещей: 1.Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С); 2. Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days); 3. Разбор реальных проблем и рекомендации экспертов по проектам слушателей. Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике руководителей проектов внедрения. Ведущая курса - Мария Темчина.

от 11000 рублей

Как завести у себя в команде код-ревью. Отвечаем на вопросы

Статья Программист Нет файла Бесплатно (free) Рефакторинг и качество кода

Дадим советы как начать использовать у себя в команде код-ревью (code-review), а также ответим на вопросы читателей.

17.07.2019    6444    ivanov660    29       

По следам код-ревью

Статья Программист Стажер Нет файла v8 Бесплатно (free) Рефакторинг и качество кода

Приведу примеры с картинками и небольшим пояснением по вопросам, связанным с код-ревью (обзором кода).

09.07.2019    9299    ivanov660    110       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

Управляй качеством кода 1С с помощью SonarQube

Статья Программист Нет файла Россия Бесплатно (free) Практика программирования

Управляй техническом долгом проектов 1С с помощью SonarQube. В статье рассматривается пример применения SonarQube при разработке.

07.07.2019    26189    olegtymko    214       

Что такое рефакторинг и в чем его цели

Статья Программист Нет файла v8 Бесплатно (free) Практика программирования Рефакторинг и качество кода

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

30.10.2018    7433    eu_genij    34       

Управление ИТ-проектами. Модуль 2: продвинутый онлайн-курс по классическим методам управления проектами. Вебинары проходят с 12 марта по 11 июня 2020 года. Промо

Продвинутый онлайн-курс по классическому управлению ИТ-проектами позволит слушателям освоить инструменты из PMBoK® и 1С:Технологии корпоративного внедрения и научиться их применять для проектов любого масштаба. Курс включает в себя 12 вебинаров и 12 видеолекции, разбор кейсов и рекомендации экспертов по проектам слушателей. Ведущая курса - Мария Темчина.

от 13000 рублей

Учебный курс. Повышение качества разработки. Ошибки программы

Статья Программист Нет файла Бесплатно (free) Практика программирования Математика и алгоритмы Рефакторинг и качество кода

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекции № 3,4,5. Эти лекции посвящены ошибкам программ, их классификации и способам исправления

10.07.2018    17404    Артано    92       

Управление техническим долгом - Концепция Continuous Inspection

Статья no Нет файла Бесплатно (free) Управление проектом Практика программирования

Сегодня я вам хочу рассказать про тему «Управление техническим долгом» – что это такое, как с этим бороться и почему с этим надо бороться.

30.06.2017    16750    nixel    16       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Как писать неподдерживаемый код

Статья Программист Нет файла Бесплатно (free) Практика программирования Рефакторинг и качество кода

Вы хотите чтобы Вы были самым ценным сотрудником компании? Чтобы Вас носили на руках? Тогда эта статья для Вас. Эти знания передаются из поколения в поколение и представляют особую ценность в умелых руках.

25.08.2015    21513    vandalsvq    61       

Типичные ошибки, некоторые вопросы качества и эффективности работы при разработке в 1С

Статья Программист Нет файла Windows Бесплатно (free) Практика программирования Рефакторинг и качество кода

В этой статье мы приведем набор типичных и часто встречающихся ошибок при разработке в 1С (скорее всего особенно актуально для начинающих программистов). Предложим набор советов и рекомендаций по улучшению качества кода и работы при использовании типового инструментария. Это первая часть из 24 пунктов. Бонусом к каждому пункту мы привели разъяснения и комментарии.

15.02.2015    21776    ivanov660    40       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Как повысить качество разработки своих проектов под 1С?

Статья Программист Нет файла Бесплатно (free) Управление проектом Рефакторинг и качество кода

Здравствуйте уважаемые коллеги. Мы – небольшое франчайзи (4 человека), которое занимается разработкой под 1С вот уже более 2х лет. После первого года работы возникли некоторые проблемы с качеством кода, поскольку начался стремительный рост сложности проектов и, соответственно, начало появляться большое количество неприятных ошибок. В статье я постараюсь рассказать о тех мерах, которые мы приняли для повышения производительности труда программиста и качества написанного им кода. Кому интересно прошу под кат.

11.03.2013    24258    akomar    80       

Мастер-класс от Poppy (практикум по рефакторингу)

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Практика программирования

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

04.11.2008    17032    poppy    32       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Основы менеджмента кода в 1С

Статья Программист Нет файла Россия Бесплатно (free) Практика программирования Математика и алгоритмы

Продолжаем тему рефакторинга, начатую на примере "Глокой Куздры" Итак, каковы основные принципы поддержания кода в рабочем состоянии?

17.10.2008    30301    keleg    194