Table of contents
沟通的场景
当我们在一个团队中工作时，不可避免的需要和其他人交流。我们需要和产品经理、设计师、测试人员、其他程序员、运维人员、领导等等进行交流。我们需要和他们讨论需求、设计、实现、测试、部署、维护等等。
每天早上的晨会中，我们需要和团队成员讨论昨天的工作、今天的计划、遇到的问题。
在每个版本的迭代之前，我们需要和产品经理、设计师、测试人员等等讨论需求、设计、测试。
在制定技术方案时，我们需要和其他程序员讨论技术选型、架构设计，并整理文档，在技术评审会上讨论
在功能开发过程中，我们需要和其他程序员讨论接口、实现。
在开发完成后，我们需要和测试人员讨论测试用例、测试结果。
在部署上线之前，我们需要和运维人员讨论部署方案。
每个月的月度总结中，我们需要和领导讨论工作成果、工作计划。
当团队招聘新人时，我们要对面试者进行面试，了解他的技术能力、沟通能力，以及是否适合团队。
沟通的目的
沟通的目的是为了让别人明白你的意图，让别人明白你的想法，让别人明白你的需求，让别人明白你的计划，让别人明白你的问题，让别人明白你的解决方案。
为了达到这个目的，我们要注意这几点：
- 明白自己想说什么: 在让别人明白我们的意图之前，我们首先得明确自己的观点，以及如何支撑这个观点。
- 明白对方想听什么: 面对不同的人，我们需要表达的观点是不同的。当面对产品经理时，我们需要表达的是技术方案是否能满足需求，我们的实现方式如何在用户手里产生价值；当面对测试人员时，我们需要明确代码是否能通过测试用例；当面对领导时，我们需要说明工作成果和工作计划。
- 选择时机: 如果我们要说服开发者接入链路追踪系统，最好的时机是在他们遇到难以调试的问题时，而不是在他们正在忙于开发新功能时。
- 选择风格: 当我们在总结工作时，我们可以用图表、表格、文字等不同的风格来表达，重点说明工作成果和工作计划。当我们在讨论技术方案时，我们可以用流程图、时序图、类图、时序图等不同的风格来表达，这时候可能需要深入到接口定义和实现细节。
- 包装: 必要的包装可以让我们的观点更容易被接受。比如，我们可以用整洁的排版，在 ppt 中添加图片、表格。
- 让听众参与: 在准备工作中，我们可以考虑听众的需求，让他们参与到我们的讨论中。比如，我们可以在讨论技术方案时，让其他程序员参与到我们的讨论中，让他们提出自己的观点，让他们参与到技术选型、架构设计中。
- 做倾听者: 听取别人的意见，让别人觉得自己的意见被重视，也更容易达成共识。
- 回应别人: 当别人提出问题时，我们需要及时回应，让别人知道我们已经收到了他的问题，我们会尽快回应。
- 把代码和文档绑在一起: 注释源码是一个绝佳的机会，可以用来记录那些在其他地方无法记录的项目细节：工程上的权衡，为什么要做决定，放弃了哪些替代方案，同时也能帮我们自己理清思路。
沟通原则
DRY
Don’t repeat yourself: 在一个系统中，每一处知识都必须单一、明确、权威地表达
在代码重构中，有一个三次法则（rule of three），三次法则的要求是，允许按需直接复制粘贴代码一次，但如果相同的代码片段重复出现三次以上的时候，将其提取出来做成一个子程序就势在必行。
在平时的协作过程中，我们也会遇到重复的情况。比如，我们可能在多个不同的模块中实现了同样的功能。为了解决这样的问题，我们应该鼓励开发人员之间积极频繁的交流。可以来一次日常 Scrum 晨会用于讨论常见的问题。对于已经做过的工作，我们可以提高复用率，比如把一些通用的功能封装成库，让其他人可以直接使用。或者把这些问题记录在 wiki 上，以便后续查阅。
ETC
Easy to change, 能适应使用者的就是好的设计
ETC里有一个隐含的前提。多条路线中的哪一条更易于将来的变更。我们可以有意识地问自己：“我刚刚做的事情是让整个系统更容易改变还是更难改变？”当你保存文件时问一遍，当你写测试时问一遍，当你修复Bug时也问一遍。
当我们找不到线索时，可以做两件事：
- 假设不确定什么形式的改变会发生，你也总是可以回到终极的“容易变更”的道路上：试着让你写的东西可替换。
- 在工程日志中记下你面临的处境：你有哪些选择，以及关于改变的一些猜测。在源码中留个标签，以便之后必须修改这块代码时，进行回顾并给自己留下反馈记录。