从chapter4至chapter6，围绕着构建过程的合作讨论构建之法，而合作与个人工作的区别却以一个微妙的问题为开端：阅读别人的代码有多难？
两人合作：（驾驶员与领航员）
合作要注意代码风格规范与设计规范，如语句分行便于单步执行、使用“匈牙利命名法”等等。这里有趣的一点是，书中认为goto为函数提供单一出口，有助于程序逻辑的清晰体现，但是一些从事教学的教授认为goto语句影响代码的可读性，尽量减少使用，二者均有一定道理。之所以如此注重代码规范，非常重要的一个因素就是错误处理往往需要项目80%的时间。
两人合作不同阶段（萌芽，磨合，规范，创造，解体）有着不同的技巧，如何影响对方没有绝对正确或错误的方法，只有合适不合适的问题；正确给予反馈，着重于反馈层次的最外层（行为和后果），不要贸然深入中间层（习惯和动机）和最内层（本质和固有属性）。
写程序的目的不是“为赋新词强说愁”，而是为了解决问题，所以我们要慎重使用这些语言的高级特性，尽量使用简洁的方法。软件开发则是一个社会性的活动，“破窗效应”提醒我们团队成员必须严格执行代码规范。
团队和流程：（乐团？特工队？社区？）
对于团队模式的叙述是我非常喜欢的部分，引用Michael Jordan的一句话“Talent wins games, teamwork wins championship.”，作者采用类比方式介绍了一些优秀的团队模式，解决紧迫性问题时需要SWAT模式，领域处于稳定成长阶段时需要Orchestra模式，秘密状态下的项目需要Skunk Work Team，还有个性敏捷的Jazz Band等等。
团队开发软件流程中，支持code-and-fix，原本我也疑惑为什么老师一直强调要让顾客尽早参与到项目中来，但是改进与变形的瀑布模型告诉我们正是模拟版本甚至是不成熟有残缺的版本，所以才需要收集反馈改进步骤，让用户及早介入、讨论、复审。这里叙述的RUP与之前的PSP相辅相成。
敏捷流程：
敏捷开发重计划、重沟通，这RUP和Six Sigma有一些相似之处。流程图如下：
燃尽图每天跟踪了三个时间值：实际剩余时间、预估剩余时间、实际花费时间。正如我们时常调侃的“ddl是第一生产力”“新时代特色爆肝主义”一样，这样的燃尽图是对我们的绝佳督促和进度参考。
Sprint/Scrum将项目的众多需求分而治之，强调短时间的迭代与多次迭代中的不断总结，这样让每个人都集中注意力解决自己的问题，又能为团队提出自主性的想法。预期说它是一种模式，不如把Agile认为是一股思潮或一种价值观。虽然有许多方法论与实践，但正如马克思主义原理的不败言论“具体问题具体分析”，敏捷流程永远不能脱离适用的范围。
Q: 读书时遗留一个问题，书中以“简明，易读，无二义性”为代码风格原则，这三者是否有先后顺序？当出现冲突时如何平衡？书中强调的“保持简明，让代码更容易读”是不是暗示“易读”是核心原则？