Как вы узнаете, является ли программное обеспечение хорошим или плохим, основываясь на эмпирических показателях?

В настоящее время меня просят взглянуть на проект, который закончил разработку ядра пять месяцев назад, но все еще имеет высокий уровень дефектов. Получается, что примерно на каждые 10 исправленных дефектов мы поднимаем как минимум 4, а в некоторых случаях 8 дефектов.

Я считаю, что практика кодирования у продавца плохая, и по этому поводу существует общее согласие. Однако мне интересно, есть ли структурные проблемы с программным обеспечением? Плотность дефектов является полезной мерой, но, скорее, если основное программное обеспечение написано плохо, то все, что делает поставщик, - это решает проблему.

В инфраструктуре это более определено, если что-то плохо построено, какие измерения вы можете использовать для программного обеспечения помимо дефектов на LOC?

Продукт находился в стадии устранения дефектов в течение 4 месяцев и до сих пор не устранен достаточно критических дефектов. Мы не внедряем новую функциональность, а просто исправляем проблемы регрессии.

Это указывает на проблему качества разработки, которая не является обоснованной. Однако, если сам продукт в корне ошибочен, это другая проблема. Беспокойство вызывает то, что базовая кодовая база была написана плохо и имеет ограниченную документацию, все внешние разработчики переносят проблему с А на Б. Как только внутренние команды разработчиков вступят во владение, я обеспокоен тем, что им придется фундаментально переписать код, чтобы получить его функциональным.

Поэтому, когда вы принимаете продукт от третьей стороны и просите его поддержать, какие критерии приемлемости вы бы использовали для определения стандартов?

Помимо того, что наш ведущий разработчик проводит рецензирование кода на выпуск, не уверен, что еще можно сделать?

Вы не

Качество программного обеспечения действительно сложно измерить объективно. Достаточно сложно, что нет решения. В этом ответе я воздерживаюсь от размышлений над вопросом, можно ли вообще найти решение, но просто укажу, почему определить его будет действительно сложно.

Рассуждение о статус-кво

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

Есть проекты, в которых менеджеры решили применить определенные метрики. Иногда это работало, иногда нет. Я не знаю каких-либо существенных корреляций. Особенно критическое системное программное обеспечение (например, самолеты, автомобили и т. Д.) Предъявляет множество требований к метрикам для «обеспечения» качества ПО - мне не известны какие-либо исследования, показывающие, что эти требования действительно приводят к повышению качества, и у меня есть личный опыт наоборот.

Рассуждение контрразведки

Также уже намекается на Килиана и в более общем виде формулируется как «каждая метрика может и будет сыграна».

Что значит играть в метрику? Это забавная игра для разработчиков: вы гарантируете, что значения метрик выглядят действительно хорошо, в то же время делая действительно дерьмовые вещи.

Допустим, вы измеряете дефекты по LOC. Как я буду играть в это? Легко - просто добавьте больше кода! Создайте глупый код, который приводит к бездействию более 100 строк, и внезапно у вас появляется меньше дефектов на LOC. Лучше всего: вы таким образом снизили качество программного обеспечения.

Недостатками инструментов злоупотребляют, определения растягиваются до максимума, изобретаются совершенно новые способы ... в основном, разработчики - действительно умные люди, и если в вашей команде будет только один разработчик, который будет весело играть в метрики, тогда ваши метрики будут сомнительными.

Это не значит, что показатели всегда плохие, но отношение команды к этим показателям имеет решающее значение. В частности, это подразумевает, что это не будет работать хорошо для любых отношений субподрядчика / стороннего поставщика.

Рассуждение по неправильному таргетингу

То, что вы хотите измерить, это качество программного обеспечения. То, что вы измеряете, это один или несколько показателей.

Существует разрыв между тем, что вы измеряете, и тем, что, по вашему мнению, вам это скажет. Этот разрыв довольно большой.

Это происходит постоянно во всех сферах деятельности вокруг нас. Когда-нибудь видели решения, основанные на KPI (ключевые показатели эффективности)? Это та же самая проблема - вы хотите, чтобы компания преуспела, но вы измеряете что-то другое.

Рассуждение количественно

Метрики могут быть измерены. Который является единственной причиной, по которой мы имеем с ними дело вообще. Однако качество программного обеспечения простирается далеко за пределы этих измеримых сущностей и имеет много общего с количественным определением: насколько читабелен исходный код? Насколько расширяем ваш дизайн? Насколько сложно новым членам команды попасть на борт? и т. д.

Оценка качества программного обеспечения только по метрикам и закрытие глаз на части качества, которые вы не можете измерить, определенно не сработают.

редактировать:

Резюме

Позвольте мне отметить, что все вышесказанное связано с объективной оценкой, является ли программное обеспечение хорошим или плохим, на основе метрик. Это означает, что ничего не говорится о том, следует ли и когда применять метрики.

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

Вы измеряете программное обеспечение А, а показатели получаются очень плохими. Тогда вы можете быть уверены, что качество кода плохое. Вы измеряете программное обеспечение B, и показатели в порядке, тогда вы не имеете ни малейшего представления о качестве кода. Не думайте, что «метрика хорошая = хороший код», когда это просто «хороший код => хорошая метрика».

По сути, вы можете использовать метрики, чтобы найти проблемы с качеством, но не само качество.

Да, вы можете сказать, что у кода проблемы с качеством, посмотрев на метрики в некоторой степени.

В частности, запустите инструмент анализа сложности на основе кода, и вы получите представление о том, является ли код хорошим или плохим.

Например, вы можете запустить исходный монитор .

Это скажет вам, насколько сложен код. Я могу сказать, что у каждой проблемной системы, которую я испытал, были плохие цифры. Сложность методов от 10 до 100 с превышением допустимых пределов. Страшные цифры. Ужасная сложность, вложенность, глубина и т. Д. Это приведет к множеству проблем, постоянной высокой частоте появления дефектов, сложным изменениям, не нарушая что-либо еще и т. Д.

Другое дело, дефекты. Со временем система должна стабилизироваться. В идеале новые дефекты должны стремиться к нулю или сглаживаться до небольшого числа, что означает, что новые и текущие дефекты должны уменьшаться со временем.

Сюжет должен выглядеть примерно так:

Дефекты с течением времени

Если они остаются постоянными или увеличиваются, значит, программное обеспечение не очень хорошее. Тебе всего 4 месяца, так что я бы отдал еще несколько месяцев в году. Через 6 месяцев или год, если у вас был постоянный поток дефектов, значит, это плохое качество. Ваша команда разработала еще один шарик грязи .

Следующие тесты. У тебя есть они? Если нет, то меньше качество, больше ошибок, больше отток. Если они у вас есть, такие показатели, как охват кода, хороши для того, чтобы понять, сколько кода покрывается, но не будут измерять качество . Я видел большие цифры покрытия кода, но реальные тесты были дерьмом. Они не тестировали какое-либо поведение или функциональность системы. Разработчики просто писали их, чтобы улучшить метрические числа для управления. Таким образом, у вас должны быть тесты, и они должны быть хорошими. Метрики покрытия кода сами по себе не являются показателем качества.

Кодовые обзоры, вы их выполняете? Если нет, то меньше качества. Это особенно важно для младших разработчиков. Если вы делаете Agile, просто добавьте задачу проверки кода в вашу историю, которая называется «Проверка кода». Если руководство хочет отслеживать цифры, вам понадобится инструмент для отслеживания таких отзывов, как Crucible . Я думаю, что цифры обзора кода или метрики здесь не так важны, кроме того факта, что они должны быть частью вашего процесса. Не каждая регистрация требует пересмотра. Но отзывы могут помочь убедиться, что люди не изобретают колесо и не пишут код, который другие не могут понять и / или поддерживать.

Наконец, вам просто нужно будет оценить код, никакая метрика не поможет. Каждый проблемный код проекта имел следующие качества:

• Плохие структуры данных. Все является строкой, или XML передается повсеместно и анализируется повсеместно, объекты бога или ненужные сложные или общие структуры данных, а не модель предметной области.
• Отсутствие организации или структуры, любой нетривиальный проект должен иметь некоторое разделение или расслоение, которое отделяет логику. Посмотрите здесь ... Если вы не видите такого типа организации или разделения (смешение логики повсюду), тогда систему будет сложнее поддерживать и понимать.
• Над абстракциями. Иногда верно обратное, система перегружена. Если все является интерфейсом и абстрактным классом, или вам приходится перемещаться по множеству классов классов «обертка», качество будет плохим, потому что новые разработчики не смогут перемещаться по объектам.
• Трудно понять код. Если вы опытный разработчик и ищете код, который трудно понять, у него будут проблемы с качеством. Мой личный показатель заключается в том, что если я смотрю на код, и за ним трудно следить, или я чувствую себя глупым, или я чувствую, что я трачу много мозговых циклов, чтобы выяснить логику, то это плохой код. Если опытным разработчикам трудно следовать, просто представьте, как это будет выглядеть для новых разработчиков. Они будут представлять проблемы.

Мой совет - провести анализ сложности кода. Не делитесь результатами, вместо этого следите за результатами, проведите независимое исследование (посмотрите на код) и определите общее состояние базы кода. Исходя из этого, сформируйте план действий и попробуйте исправить некоторые сложные области кода.

Грустная вещь, связанная с метриками, заключается в том, что в конечном итоге вы можете улучшить итоговые значения ваших метрик, но не качество, предназначенное для их измерения ...

В Visual Studio есть параметр для обработки предупреждений компилятора как ошибок. Теперь некоторые люди не понимают предупреждений и для компиляции кода будут использовать простые приемы (например, «отключение прагмы» или добавление ключевого слова «новый» к функции / свойству, скрывающему не виртуальный член базы). учебный класс).

Если у вас есть доступ к исходному коду, вы можете запустить статический анализ кода. Для проектов .Net вы можете использовать, например, FxCop или ReSharper InspectCode. При правильном использовании командой разработчиков инструменты помогут улучшить качество. Но, конечно, возможны некоторые «исправления» для удаления предупреждений без их понимания.

Вы можете посмотреть на автоматизированные тесты / UnitTests: насколько хорошо покрытие кода? Но одно только покрытие не скажет вам, проверяли ли тесты код на самом деле, или он выполнялся один раз.

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

В дополнение к сбору метрики, подобной инъекции дефектов, вам необходимо выяснить источник дефектов. Часто это связано со спецификацией.

По сути, это ошибка в спецификации, двусмысленность в спецификации, оставленная на усмотрение имплантатов, или это ошибка в реализации.

Более качественный подход - спросить, полезно ли программное обеспечение? Если вы посмотрите достаточно внимательно, вы можете найти дефекты в любом программном обеспечении. Однако, если он работает достаточно хорошо, чтобы зарабатывать деньги, то это может быть не так уж и плохо.

Снизу, нет способа узнать.

Исходный вопрос (перед философским ответом): что должен делать продукт и делает ли он это? Измерение по количеству дефектов / плотности недостаточно. Я не мог сказать, была ли это библиотека или приложение, насколько велика база кода, насколько велика проблемная область или какова серьезность дефектов. Например, несоблюдение одного из 123 форматов ввода может быть тривиальным дефектом или задержкой показа, в зависимости от важности формата, который не обрабатывается должным образом. И лучше, чем ничего - это высокий стандарт.

Предположение, которое я сделал для этого вопроса: есть разница между кодом и программным обеспечением. Я определяю программное обеспечение как то, что клиент / пользователь использует для решения проблемы, тогда как код является строительным материалом программного обеспечения.

Программное обеспечение может быть измерено только субъективно. То есть метрика, которая имеет значение для программного обеспечения, заключается в том, используют ли люди его для решения проблемы. Эта метрика зависит от поведения другого, следовательно, субъективно. Примечание. Для некоторых задач часть программного обеспечения может быть весьма полезна и поэтому считается высококачественной (Excel для расчетов), но не качественной программой для другой проблемы (Excel для воспроизведения файлов MP3).

Код может (обычно) измеряться с помощью эмпирических показателей . Но интерпретация не «да / нет» по качеству или даже по шкале от 0 до N. Метрики измеряют против стандарта. Таким образом, метрики могут найти проблемные области, определенные стандартом, но отсутствие проблемных областей не является доказательством того, что это качественный код. Например, полезные метрики: компилируется ли? Нет -> Не качество. Да -> ??? Он проходит модульный тест? Нет? Может быть? (потому что, это код качества модульного теста?), Да -> ???.

Таким образом, как доказательство Гёделя о неполноте, показанное для аксиом математики (то есть существуют математические утверждения, которые не могут быть доказаны как истинные или ложные для любого конечного набора аксиом), я не думаю, что мы когда-либо могли на самом деле ответить «это качество код?' за каждый кусок кода. Интуитивно понятно, что между метриками программного обеспечения существует соответствие между качеством и математическими аксиомами, которые доказывают правдоподобную истину или ложь.

Еще один способ сделать этот аргумент, это перейти на естественный язык. Уильям Шекспир, Льюис Кэрролл и Марк Твен - все были успешными писателями, и многие из них были любимы качеством своих произведений. И все же, какой стандарт грамматики, словарного запаса, стиля или голоса мы могли бы применить, чтобы они неизменно оценивались выше, чем у случайных учеников 12-го класса? И, хотя может быть возможно создать некоторую синтетическую меру для этих трех, как бы она оценила Книгу Иоанна (KJV), Дж. Р. Р. Толкиена, Гомера, Сервантеса и т. Д.? Затем добавьте Берроуза, Фолкнера, Хемингуэя, Сильвию Плат и так далее. Метрика не будет работать.

Я бы измерил это путем проверки (и поиска отклонений) в их процессе.

Я хотел бы найти свидетельство процесса, обеспечивающего централизованное управление исходным кодом, центральную систему сборки и процесс, обеспечивающий тестирование кода перед интеграцией в выпущенную ветку.

Я также хотел бы найти доказательства того, как они изменили свои процессы в ответ на ситуации, когда дефекты прошли процесс выпуска.

Если они не могут пройти этот уровень аудита, вы не можете ожидать, что они будут предоставлять согласованные надежные выпуски.

Если они проходят этот аудит и постоянно улучшают свой процесс, то их согласованность результатов, вероятно, со временем улучшится.

Если это не помогает, то, скорее всего, у них есть проблема с архитектурой кода, из-за которой расширение и тестирование их текущей кодовой базы проблематично, и в этом случае хороших вариантов нет.

Если вы ищете полностью автоматизированные измерения, то я рекомендую этих ребят: Группа по улучшению программного обеспечения

По сути, это совокупность различных метрик, которые могут быть автоматически извлечены из исходного кода (например, покрытие модульных тестов, размер функции, запутывание классов, дублирование, LOC и т. Д.). Эти значения затем преобразуются в 1-5 звезд.

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