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

За определениями термина «качество программного обеспечения» не грех обратиться к стандартам. Несколько определений из разных стандартов удобно приведены на одной странице wiki. И что же?! В фокусе способности программы удовлетворять потребностям Заказчика.

Итак, основной акцент делался и делается именно на функциональности. Заказчик формулирует свои функциональные требования и принимает программу тоже по «списку фич». Тестирование в большинстве случаев сводится к функциональному. Многочисленные инструменты автоматизированного тестирования решают именно этот класс задач. Да, иногда формулируются требования по отказоустойчивости или максимального приемлемого времени отклика пользовательского интерфейса, или исполнения отчета. Да, особо разборчивые могут провести даже нагрузочное тестирование. Но программа принимается на опытную эксплуатацию (а бывает, что и сразу в промышленную) при отсутствии дефектов в функциях определенного уровня, например, без критических багов. Я наблюдал этот процесс приемки многократно в проектах разного размера и у разных заказчиков, и в собственных отделах разработки, и в проектах с аутсорсингом, на разных технологиях и различной степени критичности — везде главное функциональность.

Что же, наверное, это правильно. Но достаточно ли этого на самом деле, чтобы спокойно утверждать, что мы сделали (или нам изготовили на заказ) «качественный» продукт? Что же это такое «качественное приложение»? Можно ли измерить качество, от каких факторов оно зависит, как его совершенствовать?

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

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

Ниже вы найдете несколько полезных ресурсов на эту тему:

• OWASP — The Open Web Application Security Project. Эта организация занимается вопросами безопасности web приложений. Посмотрите, например, их ролик, посвященный одной из наиболее распространенных уязвимостей — SQL инъекциям (SQL Injections)
  
  
  
• CWE — Common Weakness Enumeration. Развивает реестр и классфикатор уязвимостей в пограммном обеспечении.
  
  
• WASC — Web Application Security Consortium.
  
  
• MISRA — Motor Industry Software Reliability Association. Развивает стандарт разработки на языке C, а также С++.
  
  
• ISO 25000 Ну, а как же без ISO/IEE. Это серия стандартов оценки и требований к качеству программного обеспечения.
  

Как же теперь эту информацию можно использовать на практике? Модели, стандарты, рекомендации, лучшие практики — это всё замечательно, но требует массы времени на «усвоение».

Заранее прошу прощения за примитивность примеров на PHP. Я знаю, что использование $this в статических методах приведет к ошибке. Необходимо найти все вхождения примерно такого кода:

<?php
class MyClass {
     public $message = "A message";
     static function printMessage(){echo $this->$message;
//VIOLATION
           return;
           }
     }
?>

Или, например, не рекомендуется использовать exit() or die(), потому что будет сложно потом понять истинную причину ошибки.

<?php
$filename = '/path/to/datafile';
$f = fopen($filename, 'r') or die("Cannot open file ($filename)"); // VIOLATION
... operations on file ...
?>

Или, нужно найти как часто программисты копируют блоки кода, и, по возможности, провести работу по устранению этого недостатка для улучшения «сопровождаемости» программы.

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

• человеческий фактор — уровень квалификации, мотивации, частных обстоятельств может сильно повлиять на результат.
  
  
• слабый контроль изменений — выявленные недостатки и уязвимости нужно аккуратно фиксировать и ставить в план на исправление, а потом заново пересматривать код. Это весьма дорогая практика.
  
  
• слабая измеримость — без использования каких-либо инструментов для проведения code review практически невозможно измерять метрики качества, а следовательно, видеть процесс в динамике — помогает нам практика или нет, что можно улучшить и т.д.
  
  
• не работает для больших и старых проектов — если программа была написана много лет назад, сложная, содержит огромное количество строк кода, то невозможно себе даже представить трудоемкость и стоимость пересмотра всего кода. Реально просматривать и исправлять только изменения в новых версиях.
  
  
• стандарты для кода не универсальны — да, многие хорошие и полезные практики универсальны, но далеко не все. Очень многое зависит от технологии разработки, языка программирования, исследуемой характеристики качества.

Как было бы замечательно, если бы практика просмотра кода была лишена этих недостатков. Хочешь «перетрясти» все мегабайты накопленного кода на разных языках программирования с уверенностью и знаниями эксперта — пожалуйста. Хочешь проверять качество и отлеживать улучшения на каждом чекине — отличная идея. Хочешь видеть нормальные отчеты и графики по результатам анализа, а не только длинные списки найденных дефектов — ну, а кто не хочет? А еще бы оценить трудоемкость исправлений обнаруженных недостатков и уязвимостей, хотя бы приблизительно. И автоматически назначить задачи программистам в Jira, чтоб не отвертелись. А хорошо было бы еще…

Выходит, что в программных анализаторах исходного кода действительно есть определенная потребность. Почему же этот класс инструментов управления качеством оставался и остается у нас практически невостребованным. Я вижу здесь несколько основных причин. Во-первых, считается, это только инструмент для программиста. Например, Microsoft Visual Studio включает в свой пакет инструментов именно такой анализатор. Т.е. результаты анализа кода являются настолько техническими, что мало понятны тем, кто заинтересован в повышении качества продукта, но не готов вникать в детали. Во-вторых, относительно понятия «качества» программного продукта все еще распространено слишком узкое понимание вопроса. В-третьих, есть совершенно определенный конфликт интересов. Программист может быть вовсе не заинтересован в том, чтобы узнать о своем коде «всю правду». Руководитель разработки и так находится в постоянном цейтноте, планируя сроки выхода версий и формируя состав изменений будущих версий. Про технический долг он и так знает. Ну, выявит, анализатор еще тонну уязвимостей и недостатков — поставит в очередь. В лучшем случае. Тестировщики заняты и мотивированы выявлением ошибок в функциональности, а их руководители не видят общей картины того, как хорошо/плохо программа на самом деле сделана.

И все же. Красота же должна спасти мир, или нет?! Чистый и правильный код — это тоже красота! И мы нашли то, что искали — современный облачный статический анализатор кода — Kiuwan. Хотя бы из любопытства посмотрите на их сайт. Проверьте свои программы — это не займет больше нескольких минут времени. Испанцы сделали классный продукт!

Поддерживается целый рой технологий и языков программирования:


Objective-C, Java, JSP, Javascript, PHP, C/C++, ABAP IV, Cobol, JCL, C#, PL/SQL, Transact-SQL, SQL, SQL Forms, RPG, VB6, VB.Net, Android, Hibernate, Natural, Informix SQL

Увы, Pascal/Delphi/RAD не поддерживается. ReactJS тоже. Метрики, индикаторы, отчеты, графики — всё на самом современном уровне. Применяемую модель качества можно настраивать, а можно расширять — добавлять свои правила для своих уязвимостей. Об этом будет отдельная статья в нашем блоге.

Может интегрироваться с другими анализаторами кода — например, он может «переварить» результаты анализа кода Ruby из другого анализатора Brakeman. Постараемся сделать статью об этом в ближайшее время.

Интегрируется с Jira, SBM. Поддерживает разные системы контроля версий.

Что может не понравиться:
1) Если в вашей программе «очень много букв», то попросят денег.
2) Да, это облачный сервис. есть программа для локального анализа кода, но результаты разбора кода будут все равно отправлены в ваш личный кабинет в облако.
3) На английском

Начать можно отсюда