Code review
- регулярный code review делают меньше 50% команд shepard/492/ppt/ppt18.ppt
- 96% дефектов выявляется при просмотре кода в одиночку (не на формальном митинге) http://dl.acm.org/citation.cfm?id=167070
- количество ревьюеров не должно быть большим http://blog.smartbear.com/code-review/who-should-review-my-code/
- одиночный ревьюер находит примерно 50% дефектов, два ревьюера - примерно 75% http://www.leshatton.org/Documents/checklists_in_inspections.pdf
- разработчик, который перепроверяет свой же код, также находит примерно 50% дефектов http://smartbear.com/resources/whitepapers/best-kept-secrets-of-peer-code-review/
- количество проблем, обнаруженных во втором code review, составляет примерно 50% от количества найденных в первом, команды из 3-4-5 ревьюеров практически не дают преимущества перед двумя ревьюерами http://dl.acm.org/citation.cfm?id=331521
- code review проводится не новичками, но для новичков
- эффективность ревью сильно зависит от уровня ревьюера и его знания просматриваемого кода http://dl.acm.org/citation.cfm?id=331521
- лучшие разработчики, тим-лиды и архитекторы могут и должны тратить время на code review
- соответствие кода стандартам кодирования/форматирования должно проверяться автоматически до ревью
- наибольшее время в ходе ревью уделяется проблемам сопровождаемости и читаемости кода: поиск ошибок в чужом коде намного сложнее, чем поиск ошибок в своём, сначала его надо прочитать и понять http://dl.acm.org/citation.cfm?id=1592371 http://www.st.ewi.tudelft.nl/~mbeller/publications/2014_beller_bacchelli_zaidman_juergens_modern_code_reviews_in_open-source_projects_which_problems_do_they_fix.pdf
- некоторые компании проводят двухэтапное ревью: первый этап - зачистка, поиск и исправление проблем форматирования/читаемости, второй этап - собственно глубокое ревью
- можно выделить наиболее критические участки кода или изменения и проводить их ревью более тщательно
