读了构建之法第四第五章，这两章是在为我们描述了团队中合作的要求和一些技巧。由于我们正在进行团队的合作项目，所以再次读这一张这一章时，感到收获很多。
在第四章中，介绍了两人的合作及一些细节。首先，在两人合作中，个人能力占据很大部分，而合作的条件也很简单，只要能看懂对方的代码，并且能够做出改进，那么项目便很容易达成。做到代码规范是两人合作的标准，也是一个程序员的素质。“代码规范”可以分成两个部分：1. 代码风格规范。主要是文字上的规定，看似表面文章，实际上非常重要。2. 代码设计规范。牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。
代码风格规范中总结出几点：缩紧4个空格，行宽适应屏幕（100），{}独占一行，每行一条语句，命名有意义，注意大小写和注释。
代码设计规范中总结出几点：一个函数做一件事，函数有单一出口，错误验证等。
在第五章中，讲述了在团队中的理论还有开发流程与技巧。什么是团队呢？有这样一个例子，许多人聚在一起各自利用自己的优势找工作，一个领导者带领他们工作，结账，走人。看起来是一个领导带着许多人一起做工作，但是这不叫团队。而一个团队需要的是相互依赖，团队有这几种模式：
主治医师模式就像在手术台上那样，有一个主刀医师，其他人各司其职，为主刀医师服务。这样的软件团队中，有首席程序员负责处理主要模块的设计和编码，其他成员从各种角度支持工作。
明星模式是主治医师模式运用到极点，明星的光芒盖过了团队其他人的总和。
社区模式由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。这种模式的好处是“众人拾柴火焰高”，但是如果大家都只来烤火，不去拾柴；或者捡到的柴火质量太差，最后火也就熄灭了。“社区”并不意味着“随意”，一些成功的社区项目，都有很严格的代码复审和签入的质量控制。
业余剧团模式这样的团队在每一个项目）中，不同的人会挑选不同的角色。在下一个剧目中，这些人也许会换一个完全不同的角色类型。各人在团队中听从一个中央指挥的指导和安排。
秘密团队一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。苹果公司1980年代在研发Macin-tosh之后的系统时，就有两三个团队在不同时期进入秘密状态开发。
特工团队就像电影电视中的特工组《加里森敢死队》等一样，软件行业的一些团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题。现在还有一些专门做网站安全性服务的团队，也属于这一类型。
交响乐团模式有下面的特点
- 家伙多，门类齐全。
- 各司其职，各自有专门场地，演奏期间没有聊天、走动等现象。
- 演奏都靠谱，同时看指挥的。
- 演奏的都是练习过多次的曲目，重在执行。
爵士乐模式是另外一种演奏模式强调个性化的表达，强有力的互动，对变化的内容有创意的回应。这看上去跟“敏捷的开发模式”有点类似。这样的团队模式和上面的“交响乐团模式”在很多方面都对立，但是两种模式都产生了很受欢迎的作品，因此不能简单地说孰优孰劣。
功能团队模式很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。在这个功能完成之后，这些人又重新组织，和别的角色一起去完成下一个功能。他们之间没有管理和被管理的关系。大型软件公司里的不少团队都是采用这种模式。
官僚模式这种模式脱胎于大机构的组织架构，几个人报告给一个小头目，几个小头目报告给中头目，依次而上。这种模式在软件开发中会出问题。因为成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领导关系。跨组织的合作变得比较困难，因为各自头顶上都有不同的老板。这种模式如果应用不好，最后会变成“老板驱动”的开发流程，见后面的介绍。