пятница, 17 апреля 2015 г.

Software-Engineering Myth Busters (покрытие кода тестами, TDD, организация и распределенные команды)

Наткнулся недавно на подборку интересных исследований проведенных Empirical Software Engineering and Measurement Research Group.

Товарищи на примере деятельности команд разработки Microsoft попытались получить хоть какие то цифры отражающие влияние различных инженерных практик и процессов, например TDD на качество получаемых продуктов.

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

Влияние покрытия кода тестами на качество
Покрытие кода рассчитывается как процент (отношение) строчек кода, которые вызываются при запускаемых тестах к их общему количеству.
Казалось бы логичным считать, что чем больше покрытие - тем лучше качество. Но результаты показали, что не все так просто (кто бы мог подумать).
Одна метрика не может характеризовать качество для любых продуктов. Процент покрытия кода сам по себе ничего не говорит, если не учитывать сложность кода и частоту его использования.
Если 99% кода протестировано, но оставшийся 1% кода постоянно используется, то от 99% толку мало. Также влияет сложность кода: сложный код сложнее тестировать, и добиваться высокого процента покрытия.
Итого: важно получить большое покрытие для сложного и часто используемого кода, чем "просто некий" процент покрытия.
Еще интересная статья про покрытие: How to Misuse Code Coverage
И еще про TDD и покрытие

Влияние TDD на качество
В исследовании рассматривались результаты команды практикующих TDD и не использующих эту практику, при этом подчиняющихся одному менеджеру (видимо, чтобы убрать наводку менеджерской активности на результаты). Эти команды разрабатывают Windows, Visual Studio и MSN (в самом исследовании есть еще результаты команд IBM).
Получились такие цифры: команды с TDD писали на 60-90% лучше, чем те которые игнорировали эту практику. Но, при этом время на разработку увеличивалось на 15-30%.
Рекомендую глянуть само исследование подробней. Там приведены исходные данные в виде размера команд разработки, их опыта, применяемых языков программирования и сроков разработки.
Итог получился в виде такой табличке

Использование проверок в коде (assertions) и как оно помогает
Еще одно интересное исследование. В качестве подопытных выступили две команды двух разных компонентов Visual Studio. Тут подробно расписывать не буду, дока не маленькая. Вывод закономерен: больше ассертов - меньше багов. Но интересно, что при внедрении этой практики настойчиво рекомендуется не вводить метрик в виде отношения количества ассертов к количеству строк. Разработчик должен "чувствовать" и осознавать необходимость использования таких проверок. Кстати, статический анализ тоже поможет.

Следующие два исследования анализировали влияние организационной структуры и распределенности команды на качество кода
Кроме влияния традиционных метрик кода (code churn, code complexity, code dependencies), хочется понимать, а как на итоговый результат может повлиять организационная структура команд(ы) разрабатывающей продукт. Это исследование описывает влияние всех этих метрик. Организационные метрики получились достаточно запутанными, и я в них пока не въехал :)

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

В общем, кому охота прогрузиться цифрами на выходных - вам сюда.

8 комментариев:

  1. >>Получились такие цифры: команды с TDD писали на 60-90% лучше, чем те которые игнорировали эту практику. Но, при этом время на разработку увеличивалось на 15-30%.

    Сколько опечаток в словосочетании "нехорошо спланировали разработку" :).

    ОтветитьУдалить
  2. :) даже не знаю, что и ответить. То есть ты думаешь, что используя TDD можно писать и качественней, и быстрее?
    Согласен, интересный момент, медленнее "сейчас" или "быстрее" потом (в следующих релизах, фиксах и тп). Поэтому они и пишут про "these are decisions that managers have to make—where should they take the hit? But now, they actually have quantified data for making those decisions."

    ОтветитьУдалить
  3. Мне кажется что у каждого более менее жесткого подхода (TDD, SpecByExample) который ограничивает и явно задает условия проверки в начале есть свойство удлинения сроков. Свойство это видно внешнему наблюдателю - менеджеру, например.

    Другое дело что это же свойство в более расхлябанных процессах проявляется как затягивание сроков тестирования.


    То есть если ты как менеджер понимаешь количественный размер бедствия (удлинение сроков на разработку на 15-30% или удлинение сроков тестирования и уже не факт что на 15-30% ) то в принципе нет никакой количественной разницы.




    Другое дело разница качественная, да вот беда - как ее померять ?

    ОтветитьУдалить
  4. Ну там есть как раз качественная разница: количество пост-релизных багов с TDD на 60-90% меньше. Можно это считать за качественную разницу? Ты же не считаешь, что в тех командах, где не было TDD не было и тестирования :)

    ОтветитьУдалить
  5. "Но, при этом время на разработку увеличивалось на 15-30%." - тут учитывались только голое время на разработку или суммарное время на разработку, тестирование, багфикс, поддержку и доработку? По второму критерию TDD по-любому быстрее. А если оценивали по первому критерию, то это шулерство.

    ОтветитьУдалить
  6. Если я правильно понял, то смотрелось время до релиза (с учетом того, что в качестве критерия брались баги после релиза, но без поддержки и доработок). И скорее всего это правдоподобно - выгода (в т.ч. и в ускорении) проявляется не в первый релиз, а в последующие и как раз при поддержке для фиксов. У меня так обычно было.
    Хотя в доке не указан какой релиз подряд они TDD юзают.
    Но можешь еще раз pdf перечитать, может я ошибаюсь :)

    ОтветитьУдалить
  7. Спасибо автору за интересные материалы и хороший пост! Заставили меня задуматься о метриках, которые мы используем. Метрики - дело тонкое, и часто их используют с прицелом на подтверждение какой-то гипотезы. В данном случае гипотезой может быть: "TDD (или другая практика) позитивно сказывается на качестве продукта". Каждая практика может быть полезной, но попытки рассчитать ее полезность или оценить затраты/выгоду - это почти всегда примерные и субъективные расчеты. Возможно я просто негативно отношусь к метрикам, которые очень часто используются неправильно.

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

    ОтветитьУдалить