Не все программисты хорошо знакомы с теорией вероятностей. Казалось бы — ну какая тут беда? Кто на что учился, гениев-универсалов не бывает. Теорвер на хорошем уровне нужно знать разве что в геймдеве, криптографии ну и может во всяком финансово-статистическом софте. Ан нет! Непонимание некоторых вещей может привести к плохим результатам даже в проектах, где его применением и не пахнет. Нет никакой магии, просто мозг человека неверно оценивает некоторые вероятности и, как результат, принимает неверные решения.Итак, представим себе некоего программиста Васю. Он пишет код. Ну, потому, что он программист. Допустим, Вася — хороший программист и 75% его кода не содержит ошибок. На самом деле, я, конечно, вру и вряд ли Вася такой гуру, но опять таки — представим. Для простоты будем считать, что на каждые 100 строк его кода 75 не требуют правок, а в 25-ти должны быть найдены и исправлены ошибки. И вот мы решаем, как это сделать. Как всегда, есть куча мнений, кто-то за повальные юнит-тесты, кто-то за расширение отдела QA, кто-то за Code Review каждого коммита, игнорирующие бюджет и сроки перфекционисты за всё сразу, самоуверенные «профи» и жадные менеджеры против всего сразу. Ну как всегда. Но что-то решать надо. И вот тут появляется идея оценить ресурсы на каждый вид деятельности и профит от него. И вот давайте прикинем эффективность, например, Code Review.
Неискушенный расчет может выглядеть примерно так: Вася написал 100 строк кода, у него обычно около 75% корректного кода, 25% багов. Заставим его потратить столько же времени на Code Review — и получим в 2 раза меньше багов (12.5%). Ну потому что раз потрачено в 2 раза больше ресурсов — значит в 2 раза меньше багов.
А вот ничего подобного! Вася — это Вася. Он писал этот код вчера, и, если он же будет проводить Code Review своего кода сегодня — ничего он не найдет. Почему? Потому что.
Ну ок. Значит, если Петя (примерно той же квалификации) просмотрит его код, он уменьшит количество багов вдвое (до 12.5%). Ну потому что они примерно одинаковой квалификации, но всё-таки разные люди и получается мы тратим на этот кусок работы в 2 раза больше ресурсов, значит получим в 2 раза меньше багов. Теперь давайте посмотрим как оно есть на самом деле.
Теория вероятности говорит, что если у нас есть система из двух устройств с надежностью Х и У и для того, чтобы она дала сбой необходим сбой обоих устройств, значит общая надежность системы это 1 — (1-X)*(1-Y). Т.е. для «устройств» Вася и Петя с одинаковой надежностью 75% общая надежность будет 93,75%! Смотрите, количество багов уменьшилось не до 12.5%, а до 6.25%! Т.е. затратив на Code Review ресурсы другого человека даже аналогичной квалификации, мы снижаем количество багов не вдвое, а в четыре раза! Круто. Кроме того, учитывая, что Code Review обычно делают лучшие разработчики в команде (грубо говоря, имеющие надежность повыше «средних» 75%) и тратят они на него заметно меньше времени, чем автор на написание кода, мы получаем еще более впечатляющие результаты.
К чему это я?
Теперь, лучше представляя, что мы можем получить на выходе, вложив в Code Review некоторое количество ресурсов, мы можем легче принимать решения о применении этого и\или других механизмов повышения качества кода. Мы уже можем оперировать цифрами, а не голословным «так все делают, это правильно!» против «да ну его, и так времени нету!». Для адекватного руководства аргумент, подтвержденный цифрами, всегда будет иметь больше веса, чем просто швыряние громкими фразами.
Короткий вывод, для тех, кому лень читать всю статью
Применение Code Review (если вы его еще не применяете) поможет больше, чем поначалу кажется.