Reference
Guide
can
- Help new team members, learn from new team members
- Geographical distribution
- integration
- let different team’s interests be heard
can not
- bug hunt
- blame game
how
- keep it lightweight:
- No special rules, no pre-authorization, no designated decision makers, no formal reports.
- Don’t force it
- Don’t micro-manage:
- Don’t force your team to review every changeset, nor to follow a rigid process during the code review.
- Encourage asynchronous reviews
- Actively share interesting findings, constructs, design decisions via code review
- Treat code review as yet another state in your project workflow
- Late code review is often worse than no code review at all
- Small and frequent over large and rare
- Continuous code review (the term I call it) share all the merits of continuous integration
- you avoid late reverted code, misunderstanding, unexpected refactoring, hanging reviews for ages because they are to big and too time consuming and, most of all, skipping code review in the name of “more important tasks” at the end of the iteration.
- Do not include too many reviewers
春阳
- 代码风格
- clean code
- naming
- 单一职责
- 行为和状态离得越近越好
- 原则在业务面前是很脆弱的
- review 应该尽量review design defect（需要懂业务）， 而不是style， standard
近期评论