一、前言
经过上一次的阅读经验，这一次再阅读起来便顺畅得多了，顾名思义，这两章就是在讲我们如何在项目开发合作过程中更加顺利，软件工程既然有着“工程”二字，那就说明它并不是一个人的事情，软件工程离不开团队合作，而团队合作的最简形态就是两人合作。
二、分析与问题
引用：
既然代码复审能发现这么多问题，有这么好的效果，如果我们每时每刻都处在代码复审的状态，那不是很好么？事实上，极限编程(Extreme Programming)正是这一思想的体现——为什么不把一些卓有成效的开发方法用到极致( Extreme )，让我们无时无刻地使用他们。
——P78
问题一：随时进行的代码复审是否可以进行选择进行定期的审查？
发现代码中的Bug是很难的，在别人的代码找到的Bug更难。根据我查阅的资料表明，代码审查人员找到Bug和可维护性、可读性问题的比例是25:75，故为了不使资源浪费，消耗在了代码可读性、可维护性等问题上和Bug上的代码审查时间分配就显得很重要。而且代码复审是在互相沟通中进行讨论的，而不是相互对抗。代码如果是按照代码规范进行，这样就可以减小成员在阅读代码时的负担，对于可读性问题审查的负担就会降低，进行模块化设计也可以对代码的可维护性问题减轻负担，那么，最大的问题就是bug了，在降低了可维护性、可读性问题查找负担之后，代码复审任务量也就相对降低，相对于随时进行的代码复审，我认为可以适当选择一个时间间隔进行代码复审，比如一天、三天不等。这样能够使项目进度不至于减慢，项目问题也能得到及时的解决。
我找到了一部分的代码复审要求
问题二、团队中的成员定位与角色是否存在可变动的情况？
经过查阅资料找到了一张项目团队分工图，看起来每个人都各司其职，并不存在任务可交叉的情况。
三、后记
通过阅读我也知道了很多在团队合作的项目开发中所需要的注意事项，比如代码的命名方式等，而且在与团队成员的合作中，我们也需要找好自己的定位和任务，这样才能使团队的绩效达到最高。
原文地址：https://www.cnblogs.com/softwarewly/p/8665689.html