第八章为注重实效的项目共有六节分别是：注重实效的团队、无处不在的自动化、无情的测试、全都是写、极大的期望、傲慢与偏见。
注重实效的团队中讲如何成为注重实效的开发者的建议，当然他们也对团队有所帮助，如果个体都是注重实效的，那他对整体起的作用更大。不要留破窗户：作为整体的团队更不应该容忍代码质量的问题，不规范的不在乎质量的团队，很有可能把那些注重实效的开发者带偏。煮青蛙：整体中的个人更难觉察到作为团队所存在的问题，可以指定一个“检测员”，让他去检查团队整体进度，依赖项的准备情况，各个环节的配合等内容。交流：杰出的项目团队往往有着截然不同的个性，更能与其他团队进行配合。有一个简单的帮助团队凝聚力的方法：创立团队品牌，以品牌代指整个团队。不要重复你自己（DRY）：由于个人理解程度的不同或者新成员的加入，团队总会面临重复的内容，适当的指派一名管理员，让他专门维护这些资料，所有对此有疑问的人都不必自我寻找，只要去找管理员就行了。正交性：对于较大的团队，更应该通过功能进行组织划分，而不是工作职务。比如开发多个项目，会有多名开发，多名测试，多名设计，他们之间更应该按照具体项目进行划分，一个项目的开发，测试和设计为一个小团体。自动化：确保一致性和准确的一种很好的方式是使团队所做的每件事情都能自动化，如果还没有做到那就尝试去做。知道如何停止绘画：团队是由个体组成的，给每个成员足够的空间，并支持他们，而不是一直给他们具化各种需求。
无处不在的自动化中讲文明通过增加我们不加思索就能完成的重要操作的数目而取得进步。— 阿尔弗雷德·诺思·怀特海我们应该在尽可能多的场景下使用自动化，因为人工流程及不能保证一致性也无法保证重复性。
无情的测试中讲注重实效的程序员会受到找到自己 bug 的驱使，以免以后经受由别人找到我们 bug 带来的羞耻。早测试，常测试，自动化测试。要通过全部测试，编码才算完成。测试主要围绕三个方面进行：测试什么、怎样测试、何时测试。
全都是写中讲代码要跟文档紧密结合，我们要认真对待注释及文档，他们不是可有可无的东西。我们喜欢看到简单的模块级头注释，关于重要数据和类型声明的注释，以及给每个类和每个方法所加的简要头注释，用于描述函数的用法和任何不明了的事情。应当使用特定的格式进行注释，通常对应语言或者 IDE 有推荐的注释格式。可执行文档，即使按照特定格式进行注释，然后利用工具提取注释内容并生成文档。例如 JavaDoc有时文档撰写者和开发并不是同一人，但他们应当接受同样的原则，特别是 DRY，正交性，以及自动化原则等。
极大的期望中讲某个项目团队奇迹般的完成了一个非常复杂的项目，但却遭到用户抵制，原因是该引用没有帮助系统。所以考虑现实，项目的成功是由它在多大程度上满足了用户的期望来衡量的。要与客户之间多交流期望，了解他们的需求，而不是一味沉溺在技术的世界里。适当制造惊喜，会有些通用性的技巧能让项目获得更好的体验。
傲慢与偏见中讲注重实效的程序员不会逃避责任，相反，我们乐于接受挑战，乐于使我们的业务知识广为人知。过去时代的手艺人为能在他们的作品上签名而自豪，你也应该如此。Sign Your Work.Kent Beck 在极限编程(XP)里的建议是采用公共的代码所有权，其还要求了结对编程，以防匿名的危险。所有权的好处是能为优秀的开发带来自豪感，并且当人们在一段代码上看到你的名字时，会将其认为质量的保证。
标签：读后感,小工,注重实效,注释,程序员,文档,测试,自动化,团队 From： https://www.cnblogs.com/mine-my/p/16996565.html