第37节 解开不可能解开的谜题
1、戈尔迪斯结号称是没人能解开的结，后来亚历山大大帝来了，用剑劈开了这个结。
2、面对看似不可能解决的问题，一定要转换思路，不要受任何先人之见影响。不要在盒子外面思考，要找到盒子。
3、有时你会发现，自己在处理的问题比你以为的要难得多，总会感觉一定有更容易的方法。这时你可以退回一步，问问自己：
- 有更容易的方法吗
- 你是在解决真正的问题，还是被外围的技术问题转移了注意力
- 这件事情为什么是一个问题
- 是什么使它如此难以解决
- 它必须以这种方式完成吗
很多时候，对需求的重新诠释能让整个问题全部消失— 就像戈尔迪斯结。
第 38 节：等你准备好
1、倾听反复出现的疑虑。当你遇到一个反复让你疑虑的问题，需要注意它，给自己时间去理解，之后它可能就会变成某种更坚实的东西。
2、对于某些东西，我们可能不愿意轻易做出承诺，总希望再等等，更多意见的提出。但这很可能是一种拖延，怎么区分是有效的等待还是拖延的接口呢？我们应该快速地构建原型，并进行推延，可能很快我们就找到了更好的解决方案。
第 39 节：规范陷阱
1、编写规范是一项重要的职责，但问题是很多人可能会陷在这里，不断地增加规范项。我们可以做这样一个尝试，写一份简单的描述，告诉别人怎样系鞋带。
这可能是一份并不能帮助他人的描述，因为对有些事情“做”胜于“描述”。因为无意识的行为更快，考虑规范反而会拖慢进度。
2、对待开发文档也一样，不要编写过于详细的规范。因为很可能开发者在思考某个问题时会想到两种不同方案，经过简单对比，选择一个更优的那个。但面对严格的规范文档，一步步思考，这更可能束缚开发者的发挥。
第 40 节：圆圈与箭头
1、设计文档里的圆圈和箭头用来解释他们指代的作用，但这还有可能是推翻我们原先设定的证据。感觉这个是承接上一节的内容，不要被以前的假设和设计所限制，留有一定的弹性空间。
2、我们相信，盲目地采用任何技术，而不把他们放进你的开发实践和能力的语境中，这样的处理日后可能会让你后悔。
3、不要迷信工具以及各种方法学，注重实效的程序员会批判地看待他们，并从中提取精华，融合成每个月都在变得更好的一套工作习惯。
第41节 注重实效的团队
1、书籍的前几章讲了几条如何成为注重实效的开发者的建议，当然他们也对团队有所帮助，如果个体都是注重实效的，那他对整体起的作用更大。
2、不要留破窗户：作为整体的团队更不应该容忍代码质量的问题，不规范的不在乎质量的团队，很有可能把那些注重实效的开发者带偏。
3、煮青蛙：整体中的个人更难觉察到作为团队所存在的问题，可以指定一个“检测员”，让他去检查团队整体进度，依赖项的准备情况，各个环节的配合等内容。
4、交流：杰出的项目团队往往有着截然不同的个性，更能与其他团队进行配合。有一个简单的帮助团队凝聚力的方法：创立团队品牌，以品牌代指整个团队。
5、不要重复你自己（DRY）：由于个人理解程度的不同或者新成员的加入，团队总会面临重复的内容，适当的指派一名管理员，让他专门维护这些资料，所有对此有疑问的人都不必自我寻找，只要去找管理员就行了。
6、正交性：对于较大的团队，更应该通过功能进行组织划分，而不是工作职务。比如开发多个项目，会有多名开发，多名测试，多名设计，他们之间更应该按照具体项目进行划分，一个项目的开发，测试和设计为一个小团体。
7、自动化：确保一致性和准确的一种很好的方式是使团队所做的每件事情都能自动化，如果还没有做到那就尝试去做。
8、知道如何停止绘画：团队是由个体组成的，给每个成员足够的空间，并支持他们，而不是一直给他们具化各种需求。
第42节 无处不在的自动化
1、文明通过增加我们不加思索就能完成的重要操作的数目而取得进步。— 阿尔弗雷德·诺思·怀特海
2、我们应该在尽可能多的场景下使用自动化，因为人工流程及不能保证一致性也无法保证重复性。
3、在一些特定场景下我们可以选择适当的工具进行自动化处理：
- 执行周期任务时可以使用 Cron
- 项目编译时虽然可以使用 IDE，但是 Makefile 更适合自动化场景
- 使用生成代码解决不得不做的重复性代码问题
- 构建自动化，其实就是目前比较常用各类 CI/CD 工具
- 自动化管理，这是一种更自由的自动化场景，比如要回复 Email，要发布网站，审批流程等，这些可以使用 Shell 或者 Perl、Python 等高级脚本语言。