This document discusses how to improve software quality through code reviews. It begins by stating the goals of code review, such as improving code quality, sharing knowledge, and educating developers. It then discusses classification of code reviews from less to more formal. The document outlines some best practices for code reviews, including having a reviewer and author, choosing reviewers strategically, and driving the review in different ways. It provides answers to common questions about organizing effective code reviews and leaves with tips, such as tracking reviewers, using checklists, and ensuring comfortable conditions for all.
34. 1. ATR (Author driver review) Yep, yep I’ve added a couple of new interfaces. There are the implementation. A reviewer An author
35. 2. RTR (Reviewer driven review) Hmm… I don’t understand what you try to verify using this test. Actually, I’m also a little bit confused … A reviewer An author
38. What to review? Look at code changes/differences Review whole solution Identify methods/functions and classes
39. How to organize code review? Use changes package (email, patch, etc.) Use separate branch in VCS Use distributed VCS Code exchange tools built in IDE Specialized instruments
Так, что-то я не понимаю, что ты проверяешь этим тестом.
Строчки дока, количество найтденных ошибок, ....
Aleksey: before in most cases because of trunk should contain only good code.
Есликоднепроходитревьювторойраз, тоонсчитаетсяопасным и ревьювитсяещекем-тоЕслизамечанияпростые, тоониисправляются в паресразуприревьюЕслизамечанийоченьмного, тоониразбиваютсянаполноценныезадачичтобынезатягиватьЕсликоднепрошелревьювовторойраз и естьсерьезныезамечания, тоонобязательноделается в пареРевьюсчитаетсямаксимальнымприоритетом, нонепрерываеттекущейзадачи (ждемперерыва)Задачанеможетпровисетьнаревьюдольшечемдоследующегодэйлискрама