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), хочется понимать, а как на итоговый результат может повлиять организационная структура команд(ы) разрабатывающей продукт. Это исследование описывает влияние всех этих метрик. Организационные метрики получились достаточно запутанными и я в них пока не въехал :)

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

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

Update: еще одно исследование "Test Code Quality and Its Relation to Issue

Handling Performance"