4 ms·
My recommendations when checking in a new feature or substantial change: 1. Meet in person 2. The coder should print out copies of the diffed code for each
by comatose_kid 12y ago
My recommendations when checking in a new feature or substantial change:
1. Meet in person
2. The coder should print out copies of the diffed code for each attendee
3. Have roles in the meeting - someone to read the code, someone to capture bugs + severity, and the rest are there to review the code
4. Coder takes documented defects, fixes them and reports back to the group with diffs.
5. Metrics can be kept, used as feedback to improve process.
Usually 4-5 people are sufficient for a large chunk of functionality.
Is this process slower than gerrit? yes. Do you get better feedback, and better understanding (at a team level) of the code base? yes.
I haven't seen software that really emulates this experience - there is an interesting opportunity here.
- xyzzy_plugh 12y agoThis is very much a cultural thing. I don't necessarily agree that you get better feedback or better understanding through an in-person meeting. In my experience tools like gerrit allow developers to learn and review at their own pace, and provide well-articulated, thought-out feedback. Note also that a large amount of modern development still occurs on mailing lists. It's all about culture.