交流
显然，团队中的开发者必须相互交谈，给出了促进交流的建议，但是人们很容易忘记，团队本身也存在于更大的组织中，
团队作为实体需要同外界明晰地交流。课上老师也经常讲，公司里面有每天的站立会议，每天进行沟通交流，没有交流的团队就
跟每个程序员单干没有什么区别，只是给程序员找了个同伴而已。同时交流也会催促大家进行更好的工作，每次的交流，大家
都会说说自己做了什么，还有什么没做，这样也起到了自我督促的作用。
无情的测试
测试是程序员工作的有机组成部分，而且是非常重要的部分。对于注重实效的程序员而言，编程工作直到所有测试都跑过之后才算完成。
测试包括单元测试、集成测试、和验证校验测试，还要考虑资源限制和极端情形。作者详细介绍了多钟类型的测试，可见他们对于
测试的重要性的确很重视。大多数开发者都讨厌测试。他们往往会温和地测试，下意识地知道代码会在哪里出的问题、并避开那些薄弱的问题。
。寻找bug有点像是用网捕鱼。我们用纤小的网（单元测试）捕捉小鱼，用粗大的网（集成测试）捕捉吃人的鲨鱼。
有时候鱼会设法逃跑，所以为了抓住在我们的项目池塘里游动的，越来越多狡猾的缺陷，我们要补上我们发现的任何漏洞。
敏捷开发
已经推行了二十余年，有很多成功的实践。但是也出现了有害的“打包敏捷"的做法。有些号称采用敏捷的公司却出现了更多的管理
层级和更正式的报告。这些做法与敏捷原则背道而驰。作者觉得有必要重新强调敏捷宣言的四大基本原则。敏捷是个原则，其本质是
应对变化，而不是固化的流程。他们甚至认为，“永远也不会有敏捷流程“。他们提供的敏捷模式是极其简单的反馈过程：评估当前局势；
采用有意义的最小步骤往目标推进一步；评估结果，修正任何发现的问题；然后重复以上步骤直到最后成功。在作者看来，快速反馈循环
应该应用在开发的各个层面上，从最底层的代码修改到最高层的项目规划，也包括团队流程