话题7: 交流
我们每天的大部分时间都花在了交流上，所以需要把它做好。
作者提出，把你平常用于交流的语言当成是另一门编程语言。你应该像写代码一样用自然语言写文章：尊重DRY（Don't repeat yourself）原则、ETC（easy to change）、自动化，等等
作者提供了如下几个想法：
- 了解听众
- 明白自己想说什么
- 选择时机
- 让你的文档美观
- 让听众参与
- 做倾听者
- 回应别人
- 把代码和文档绑在一起
对于上述的说法，我想挑几个有意思的聊聊：
1.了解听众
传达信息的过程才算是交流。
为了把信息送达，你需要了解受众的需求、兴趣和能力。
假设你想提出建议，用一个基于网页的系统让最终用户提交错误报告。
根据听众的不同，你可以用很多不同的方式来描述这个系统。
最终用户更喜欢每天24小时都能随时提交错误报告，而不用在电话里等着。
市场部门能够利用这个功能来促进销售。
支持部门的经理们有两个理由感到高兴：少雇员工，问题报告可以自动化。
最后，开发人员可能乐于积累一些基于网页的架构技术的经验，或是尝试一下新的数据库引擎。
通过对每个小组进行适当的游说，你能让他们都为你的项目感到兴奋。 与所有的沟通形式一样，这里的窍门是收集反馈。不要只是等待问题的出现：把它问出来。
你可以通过与对方互动，来获知对方的需求。你需要在交流的过程中，不断提高对听众的了解。
2. 明白自己想说什么
在正式沟通之前，你得先计划好你想说什么，写一个大纲，然后问自己：“这是否用正确的方式向我的听众传达了我想表达的东西？”精炼到不能更精炼为止。
3. 选择时机
现在是星期五下午六点，审计人员已经进驻了一周。你老板的小儿子正在住院，外面下着瓢泼大雨，下班回家道路上的经历肯定会变成一场噩梦。这时候请她给你的笔记本电脑升级内存，可能不是个好时机。理解听众想听什么的一个角度，就是搞清楚他们的优先事项是什么。当经理因为丢了一些源码而刚被老板教训了一通时，抓住机会找他谈有关代码仓库的想法，他更容易听得进去。
在聊某件事前，思考一下：现在是聊这件事的好时机吗？
4. 让你的文档美观
随便一个厨师（或者是美食频道的主持人）都会告诉你，仅仅是糟糕的外观就能毁掉你在厨房里埋头苦干几个小时的成果。
看看软件包里的实例文档，学习一下样式和布局。检查一下有没有错别字。
5. 做倾听者
如果你不听他们的，他们也不会听你的。
通过提问鼓励人们交谈，试着让他们总结你的发言。
把会议编程一场对话，你将更有效地表达你的观点。
尊重就像一个皮球，你只有把球拍出去，球才可能弹回来。表达尊重的方式之一，认真倾听。
6. 把代码和文档绑在一起
务实的程序员将文档视为整个开发过程的一个组成部分。为了让编写文档变得更容易一点，我们要避免重复劳动和浪费时间，让文档总是在手边——直接写在代码里。
无需给每个函数、数据结构、类型声明都分别加上注释。这种注释方式会导致代码更难维护：一旦你想改点什么，就需要同事修改代码和注释，项目进度紧急的时候，很容易漏掉注释的修改，导致代码和注释不同步。
将非API的注释限制在只用来讨论其为何存在及其意图、目标。
当代码已经展示了事情怎样完成时，注释是多余的--因为这违反了DRY原则。
注释源码是一个绝佳的机会，可以用来记录那些在其他地方无法记录的项目细节：工程上的权衡，为什么要做决定，放弃了哪些替代方案，等等。
