Что общего между багами и японцами?

Просто и те и другие часто живут довольно долго. Про средний возраст японцев Вы сможете прочесть где-нибудь в другом месте, а про возраст ошибок здесь. Все конечно знают, что некоторые ошибки обнаруживаются и исправляются практически сразу, на обнаружение других требуется время, а некоторые могут быть обнаружены по прошествии многих лет либо не обнаружены вообще. Не сложно сделать предположение о том каких ошибок больше, ну а если интересны конкретные цифры, то можно воспользоваться MSR Tools.

Наглядно возраст всех исправленных ошибок можно представить в виде распределения времени жизни ошибок. Временем жизни ошибки я называю период времени с момента её внесения в код до момента её исправления. По оси OX — время в днях, по оси OY — доля ошибок, время жизни которых не превысило времени t. Ниже примеры такого распределения:

django - время жизни ошибокдля Django,

wordpress - время жизни ошибокдля WordPress,

apache - время жизни ошибокдля Apache HTTP Server,

nhibernate - время жизни ошибокдля NHibernate.

Подозрительно одинаковые! Но это не означает, что выше упомянутые проекты делаются одними и теми же людьми или имеют общую кодовую базу. Это означает, что вне зависимости от проекта, его назначения, языка программирования, подготовки кадров, применения различных методологий и тому подобных вещей, процесс внесения и исправления ошибок всегда подчиняется одним и тем же законам теории вероятностей. То есть организация процесса и сложность задачи разумеется влияют на плотность ошибок, а значит и на качество, но полностью исключить появление ошибок не могут в принципе. Поэтому повышение затрат на качество не обязательно приносит соизмеримую отдачу, но об этом как-нибудь в другой раз.

Как это можно использовать? Да конечно для оценки надёжности исходного кода, чтоб его! И если Вы спросите в чём мерить надёжность, то я отвечу, что есть много способов. Один из них, например, заключается в оценке вероятности нахождения ошибок в коде. Имея распределение времени жизни ошибок и зная возраст кода, Вы можете оценить вероятность нахождения ошибок в этом коде. Чем не мера надёжности?!

6 комментариев: Что общего между багами и японцами?

  1. Alexei Barantsev говорит:

    Что-то непонятно ничего :)

    Можно поподробнее про то, как вышеописанную информацию можно использовать для каких-нибудь практических целей?

    • Semyon Kirnosenko говорит:

      Последний абзац читали? Это простой пример. На практике всё делается несколько сложнее, и не раками естественно, а программно. Можно например получить прогноз какие модули будут содержать наибольшее число ошибок по результатам релиза.

      • Alexei Barantsev говорит:

        А поподробнее? Выше же речь шла про соотношение сроков жизни дефектов, а не про абсолютные их количества.

        • Semyon Kirnosenko говорит:

          Берём кривую для NHibernate и видим, что примерно 20% дефектов имеют небольшой период жизни до 10 дней. Доля таких дефектов для NHibernate заметно ниже, чем для других проектов. Объяснить это можно тем, что при разработке проекта применяются юнит-тесты. Также общая плотность ошибок для NHibernate ниже. Как следствие, в общей массе дефектов бОльшую долю составляют дефекты нетривиальные, на обнаружение которых требуется время.

        • Alexei Barantsev говорит:

          Сомнительные рассуждения.

          1. При разработке Django тоже применяется модульное тестирование, тесты там весьма хороши. Почему там не проявляется эффект, подобный NHibernate?

          2. Время (до 10 дней или до 20 дней) скорее всего определяется длиной релизного цикла, поэтому сравнивать эти времена для разных проектов совершенно бессмысленно.

          3. Дефекты, обнаруживаемые модульными тестами, как правило вообще не заносятся в трекер, поэтому на графике отражены только остальные дефекты, среди которых распределение по «сложности» всё равно будет примерно одинаковым.

          4. Под «временем на обнаружение», видимо, подразумевается «время на локализацию», ну и плюс время на исправление. Поэтому, глядя на график NHibernate, с его переломом в районе 20%-ной отметки, я бы сказал, что разработчики быстро исправляют простые дефекты, но с неохотой исправляют более сложные дефекты :) Хотя может быть и это тоже объясняется организационными причинами — простые дефекты устраняются сразу, а более сложные — в специально выделенное время в релизном цикле.

          Так что делать вообще какие бы то ни было выводы на основании изучение подобных графиков мне кажется сомнительным занятием, сродни гаданию на кофейной гуще :)

        • Semyon Kirnosenko говорит:

          >> При разработке Django тоже применяется модульное тестирование

          Вот этого я не заметил. Но тесты эти видимо не так хороши как в NHibernate. Просто сравните плотности ошибок для этих проектов.

          >> Почему там не проявляется эффект, подобный NHibernate?

          Не факт что он не проявляется. Факт что он не так заметен.

          >> Время (до 10 дней или до 20 дней) скорее всего определяется длиной релизного цикла

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

          >> Дефекты, обнаруживаемые модульными тестами, как правило вообще не заносятся в трекер

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

          >> бы сказал, что разработчики быстро исправляют простые дефекты, но с неохотой исправляют более сложные дефекты :)

          Кстати тоже вариант заслуживающий рассмотрения :)

          >> сродни гаданию на кофейной гуще :)

          Ну это Вы загнули :)