1. 团队7～8位程序员，下班前半小时聚在会议室里，在一位主持人的引导下做代码回顾。
2. 主持人问：“咱们今天回顾哪段新写的代码？”一位志愿者在投影仪上调出今天编写的一段代码的新旧对比图。
3. 主持人说：“我们知道，如果代码编写得好，那么作者以外的其他的人就能在没有作者帮助的情况下读懂。我希望一位不是这段代码作者的志愿者，来为大家解释一下这段代码是做什么的。”一位非作者的志愿者上来逐行解释代码，并回答大家的疑问。
4. 主持人等代码解释完后，问大家：“这段代码大家还有看不懂的地方吗？”如果有问题，包括作者在内的参会者都可以回答问题，但大家都不提谁是作者。
5. 大家都看懂代码后，主持人问：“大家说说这段代码有没有好的编写模式咱们可以继续发扬？”最初几次代码回顾，好的模式很少。但是即使这样，也一定要找出一些好模式，比如“缩进很好”“花括号的位置放得很好”，诸如此类。以后几次代码回顾，要尽量找那些被改正过来的曾经的反模式，比如“这段代码用到了方法提取，且命名富有表达力，改掉了昨天‘长方法’的反模式”。只识别反模式，不识别好模式，会让代码回顾退化到令人生畏的代码审查，打消大家长期坚持的积极性。
6. 提完了好模式，主持人问：“大家说说这段代码有没有可以改进的反模式？”大家开始提反模式。注意，不要提谁是作者。
7. 主持人在整个过程中注意计时，快到半小时的时候，可以这样结束代码回顾：“今天时间也快到了，代码回顾的重点在识别模式，而不是看全部的代码。希望大家继续发扬今天识别到的好模式。另外在明天做代码回顾时，把今天识别到的反模式改进为好模式。
