代码评审小结

时间：3.23上午10：00~11：22

地点：A工位

参与人：石骞、A、B

评审内容：A写的交互检查插件

总结：

l  初期评审代码时应选择参与人员的代码来评审。业务逻辑复杂的情况下，需要代码作者解释其意图。A花了约17分钟介绍该插件的业务知识，时间有点长，但似乎又需要介绍一下大家才能统一节奏。

l  评审代码的选择需要多花点功夫。评审的代码的复杂度应当适中，既能体现出作者的风格、功底，又不至于复杂到要花比较多时间去给其他参评人员介绍业务。如何实施，还需要思考和实践

n  或者，可以在另外的场合，评审较复杂的业务逻辑的整体实现方式。总之，在一次评审活动中业务逻辑的实现，与具体代码的评审不应该放到一起

l  要确保参与评审的人员对重构有一定的认识。本来是想让他们俩自行主导我旁观并记录，但由于经验不太足，他们不太能自主发现代码中的”臭味道“，因此后续的评审更多的变成了我主导。

n  可以在结对评审之前，开个动员会。第一，让部门成员知道部门目前支持大家进行这方面的尝试。第二，挑一段较有代表性的代码，找一个较有经验的同事示范评审方式，让大家知道正确的做法。