Что такое «достаточно хорошо»? Когда речь заходит о качестве программного кода, ответ во многом зависит от того, кого вы спросите, отмечают опрошенные порталом InformationWeek эксперты.

Качество — это трудноуловимое понятие. Попросите тысячу менеджеров по кодированию описать качество, и есть большая вероятность, что вы получите примерно такое же количество определений.

«Когда я думаю о качественном коде, мне приходят на ум три характеристики: читабельность, последовательность и модульность», — говорит Лоуренс Брумюллер, вице-президент по инженерным вопросам компании Superconductive, которая предлагает Open Source-инструмент для тестирования, документирования и профилирования данных.

Он считает, что код должен быть легко доступен для всех сторон. «Это означает четкое именование переменных и методов и надлежащее использование пробелов», — объясняет Брумюллер. Код также должен быть достаточно простым, чтобы с ним можно было работать с минимальными поясняющими комментариями. «Кодовая база должна быть последовательной в том, как в ней используются шаблоны, библиотеки и инструменты, — добавляет он. — Когда я перехожу от одного раздела к другому, все должен выглядеть и ощущаться одинаково, даже если их писали много людей».

Оценка качества

Существует несколько методов, которые руководители проектов могут использовать для оценки качества кода. Относительно простой способ — это сканирование кода на предмет излишней сложности, например, вставки слишком большого количества операторов IF в одну функцию, отмечает Брумюллер. Руководители также могут судить о качестве по количеству изменений кода, необходимых для исправления ошибок, выявленных в ходе тестирования или пользователями. «Однако важно также доверять мнению ваших инженеров, — говорит он. — Они являются отличными судьями качества».

По словам Кулбира Райны, руководителя направления Agile и DevOps в компании Capgemini, основное различие между качественным и некачественным кодированием заключается в «ремонтопригодности». Поэтому лучшим прямым показателем являются операционные расходы (OPEX). «Чем ниже OPEX, тем лучше код», — говорит он. Другими показателями, которые можно использовать для дифференциации качества кода, являются масштабируемость, читаемость, возможность повторного использования, расширяемость, рефакторизуемость и простота.

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

Скорость vs. качество

Влияние скорости разработки на качество — это вопрос, который горячо обсуждается на протяжении многих лет. «Это действительно зависит от контекста, в котором работает ваше ПО», — считает Брумюллер.

Он говорит, что его организация постоянно внедряет ПО в производство, полагаясь на тестирование и мониторинг для обеспечения качества. «В этом мире необходимо найти волшебный баланс между тем, что вы обнаружите перед запуском в производство, тем, что вы обнаружите в производстве, и тем, сколько времени вам потребуется, чтобы это исправить, — отмечает он. — Хорошее эмпирическое правило гласит, что плохая ошибка должна появляться лишь в 10% случаев, и когда она появляется, вы можете исправить ее в течение часа».

Никогда не должно быть компромисса между качеством кода и скоростью, предупреждает Райна. Оба фактора должны рассматриваться как независимые. «Качество и скорость, а также безопасность должны быть встроены в код, а не рассматриваться как необязательные, нефункциональные требования», — говорит он.

Обеспечение качества

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

Аарон Оу, управляющий директор по рискам и финансовым консультациям DevSecOps в компании Deloitte, предостерегает разработчиков от заблуждения, что хорошее качество кода автоматически означает безопасный код. «Хорошо документированный, без ошибок и оптимизированный код, например, все еще может быть подвержен риску, если не соблюдаются надлежащие меры безопасности», — объясняет он.

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

Выводы

В конечном итоге, лучшим способом обеспечения качества кода является следование признанным стандартам кодирования. «Это означает, что стандартные интегрированные среды разработчика (IDE) должны регулярно проверяться с помощью различных инструментов в рамках процесса коллегиального анализа кода в организации», — говорит Райна.

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