Для начала давайте четко определим, для чего предназначен данный инструмент. Начнем издалека (потерпите пару абзацев) - попробуем разобраться, что такое "качество кода".
Качество - это совокупность характеристик объекта, относящихся к его способности удовлетворить установленные и предполагаемые потребности.
Т.е. основное назначение процесса обеспечения качества кода - удовлетворять чьи-то потребности. Вопрос - чьи?
Если бы речь шла про качество продукта - то здесь однозначно можно сказать, что основным потребителем является заказчик, который за этот продукт платит. С качеством кода вопрос посложнее. Во-первых, я не нашла четкого общепринятого определения, что это такое. Во-вторых, если Вы поищете статьи в интернете, то увидите, что потребителями этого качества могут являться как сами заказчики (т.к. код является неотъемлимой частью конечного продукта), так и сами разработчики, которые вынуждены обслуживать этот код.
Заказчикам нужно, чтобы код решал поставленные задачи, работал стабильно и с хорошей скоростью, не приводил к ошибкам и был сопровождаем. С разработчиками снова посложнее (каждый определяет для себя свои критерии качественного кода), из общего можно выделить - код должен соответствовать принятым стандартам, быть читаемым, понятным, модифицируемым.
Как видите, критерии качества для клиента и для разработчика не тождественны. Можно было бы зацепиться за "сопровождаемость", но сейчас скажу кощунственную вещь, - для клиента самый лучший код с точки зрения сопровождения - это код, которого мало. А еще лучше, которого вообще нет.
Для чего это нудное введение? Для того, чтобы четко определить, чью потребность в качестве закрывает SonarQube. А закрывает SonarQube потребность в качестве кода именно разработчиков. Можно написать отвратительный, неработоспособный код, приводящий к серьезным проблемам производительности, и при этом он пройдет все проверки. Т.е. качество кода, обеспечиваемое данным инструментом, не гарантирует качество конечного продукта. Его основная задача сделать код "красивым" и читаемым.
Теперь, если рассматривать деятельность по внедрению и сопровождению типовых/отраслевых решений (а мы именно ей и занимаемся), то ключевая задача, которую нужно решить, - это все-таки качество конечного продукта. Чтобы клиент был доволен, заплатил, а нам не приходилось бесплатно исправлять свои ошибки. И основными инструментами для обеспечения качества продукта на этапе разработки являются код-ревью и тестирование. (Переложить проверку кода на SonarQube, как мы уже выяснили, не получится - он контролирует не то качество, которое нам нужно).
У нас в команде самый простой набор инструментов: Хранилище - Gitlab - Яндекс Трекер. И пересматривать его мы в ближайшее время не планируем, он закрывает наши потребности. Разработчик выкладывает доработки по своей задаче в хранилище и переводит задачу в трекере на ревью. Код проверяется техническим архитектором на отсутствие ошибок, соответствие технической постановке и на оптимальность (он не должен приводить к проблемам производительности). И затем отправляется на тестирование.
Эта специфика выработана у нас на очень крупном сопровождении, когда мы несколько лет спасали разваливающуюся систему от архитектурных ошибок и "вполне качественного", но весьма проблемного кода. С полным правом могу заявить - неважно, оформлен ли Ваш код по всем стандартам, если ни в одном отчете нельзя получить корректные цифры, а время отклика на любое действие в системе доходит до нескольких минут. Клиент Вам в таком случае за правильно оформленные комментарии в коде спасибо не скажет.
Что мы получили после внедрения SonarQube:
- После выкладки в хранилище разработчику спустя некоторое время начинают приходить письма с замечаниями. В это время он уже переключился на работу по другой задаче. Он вынужден либо отвлекаться (что сразу влияет на результат), либо откладывать отработку замечаний на потом. Как итог - объем незакрытых замечаний копится, к тому моменту как разработчик вернется к вопросу устранения замечаний, высока вероятность, что нужный ему объект будет захвачен.
- Накопленный объем незакрытых замечаний отработать невозможно. Задачи на разработку идут непрерывным потоком и по всем сроки жесткие. Выделить время на то, чтобы сесть и отработать все замечания не получается. Тем более поправить несколько десятков (или сотен) накопленных - это не одно-два устранить. (И честно, сидеть их закрывать - очень сильно раздражает. Особенно когда 99% - это придирки к оформлению, по типу пробелов в комментариях, длины наименований методов и т.д.).
- Отработка замечаний требует времени. Если в карточке замечания написано, что устранение займет одну минуту - это вовсе не означает, что у Вас уйдет ровно минута. На самом деле дольше, особенно поначалу, пока Вы все правила не освоите. Т.е. трудозатраты на разработку чувствительно возрастают. У нас накопленный тех.долг по мнению SonarQube в рамках проекта приблизился к 10 процентам от часов, выделенных на разработку. А ведь мы еще все-таки часть замечаний отработали.
- Основное рабочее место, в котором разработчики получают обратную связь по задачам, - это Яндекс Трекер. Теперь же появляется дополнительное рабочее место, в котором тоже нужно отслеживать и отрабатывать замечания. Работать в двух рабочих местах - неудобно.
На самом деле мы могли бы все недостатки устранить. НО, мы зашли в тупик из-за отсутствия интеграции между SonarQube и Трекером. (Если кто-то знает про примеры интеграций с любыми трекерами задач, буду благодарна за обратную связь. Я пока не нашла). Если бы мы могли в карточке задачи в трекере видеть неотработанные замечания, тогда бы этот инструмент отлично вписался в наш процесс и мы бы его использовали. Замечания бы цеплялись к карточке до ревью/тестирования, и разработчик бы их отрабатывал совместно с замечаниями от аналитика/тех.архитектора.
А так, на текущий момент принято решение отказаться от использования данного инструмента т.к.:
- Он не обеспечивает качество конечного продукта для клиентов, которое для нас важнее качества кода для разработчиков. Для удовлетворения нужд наших заказчиков наш код и так - очень качественный.
- Он не избавляет от необходимости выполнения код-ревью, и не сокращает трудозатраты на его проведение.
- Увеличиваются трудозатраты на разработку. На 10-15% точно поначалу.
- Этот инструмент не вписывается в наш рабочий процесс и создает дополнительные неудобства разработчикам.
- Обеспечить отработку всех замечаний на текущем наборе инструментов мы не можем. Растущий тех. долг, как незакрытый банковский кредит, портит настроение. А себя надо любить, беречь и не допускать лишние негативные эмоции в свою рабочую жизнь.
Возможно, мы вернемся к вопросу использования SonarQube через некоторое время, если найдем решение для интеграции с трекером задач. А на текущий момент обеспечивать качество кода с его помощью ради удовлетворения тяги разработчиков к прекрасному в ущерб другим нашим процессам мы точно не будем.
P.S. SonarQube - очень хороший, дисциплинирующий инструмент. Главное, чтобы Вы четко понимали, для каких целей он Вам нужен и нужен ли. А не бездумно внедряли, потому что это "стильно, модно, молодежно".
