工作法：沟通反馈

阅读整理自《10x程序员工作法》- 郑晔，详细内容请登录 极客时间 官网购买专栏。

准确理解和表达

我们努力地学习各种知识，为的就是更好地理解这个世界的运作方式，而沟通反馈，就是我们与真实世界互动的最好方式。

常见易犯问题：讲东西直奔细节。

很多人抱怨别人不能理解自己，其实，首先应该想的问题是，自己到底有没有把话说清楚。

同时，当一个信息呈现在我们面前时，作为接收者，我们是否能够有效地接收、理解信息。

接纳真实世界的反馈

• 需要我们打开自己的接收器，把信号接纳进来，让反馈进来，这是解码的前提；

• 扩展见识，提升自己解码器的效果，更好地理解别人要表达的内容到底是什么。

人生不如意之事，十有八九，之所以很多人有如此多的不如意，很大原因在于我们对真实世界有着很多不切实际的幻想，美好的愿望并不能驱动这个世界，在软件开发中也是如此。虽然人和人生活在一个世界中，但对世界的理解却是千差万别的。

改善编解码，需要从几个角度着手，分别是：

• 编码器，让信息能输出更准确；
• 解码器，减少信号过滤，改善解码能力；
• 还有编解码算法，也就是各种来自行业的“最佳实践”，协调沟通的双方。

---

代码为谁而写

编写可维护的代码

初涉编程的程序员可能觉得能把功能实现出来的代码，就是好代码，这个阶段主要是基本功的学习，需要掌握的是各种算法、数据结构、典型的处理手法、常用的框架等等。

自我追求更好的要求，仅仅实现功能是不够的，还需要写出可维护的代码，为此，去找一些经典的书阅读。

• 《程序设计实践》（The Practice of Programming）的作者 Brian Kernighan 和 Rob Pike，贝尔实验室，参与过 Unix 的开发。
• 《代码整洁之道》（Clean Code）的作者 Robert Martin，这本书几乎覆盖了把代码写好的方方面面。

命名

名字起得是否够好，一个简单的评判标准是，拿着代码给人讲，你需要额外解释多少东西。

避免起无意义的名字，遵守编程规范。

任何人都能写出计算机能够理解的代码，只有好程序员才能写出人能够理解的代码。

写代码的目的之一是与人沟通，因为我们要在一个团队里与人协同工作。

人要负责将业务问题和机器执行连接起来，缺少了业务背景是不可能写出好代码的。

举例：很多程序员习惯的方式是用计算机的语言进行表达，就像前面一段代码中给一个变量命名为 map，这是一种数据结构的名字，是面向计算机的，而评审者给出的建议，把变量名改成 accounts，这是一个业务的名字。

虽然只是一个简单的名字修改，但从理解上，这是一步巨大的跨越，缩短了其他人理解这段代码所需填补的鸿沟，工作效率自然会得到提高。

用业务语言编程

写代码的时候，尽可能用业务语言，会让你转换一个思路。

有时候，虽然我们在用一个“xxx”的概念，但实际上，在不同的场景下，用到信息是不同的。

没有业务知识，只能笼统地用“xxx”去涵盖各种场景。

举例：在很多系统里，大家特别喜欢一个叫“用户”的概念，也把很多信息塞到了“用户”里。但实际上，在不同的场景下，它也应该是不同的东西：比如，在项目管理软件中，它应该是项目管理员和项目成员，在借贷的场景下，它应该是借款方和贷款方等等。

对业务语言有理解后，才能把这些概念很好地区分出来。

为了不让自己“分裂”，最好的办法就是把这些概念在代码中体现出来，给出一个好的名字。

最好和业务人员使用同样的语言。

领域驱动设计（Domain Driven Design，DDD）：把不同的概念分解出来，这其实是限界上下文（Bounded Context）的作用，而在代码里尽可能使用业务语言，这是通用语言（Ubiquitous Language）的作用。

小结

命名，是写程序中最基础，也是一个程序员从业余走向专业的门槛。

最初的层次是编写可以运行的代码，然后是编写符合代码规范的代码。

对于命名，最粗浅的理解是不要起无意义的名字，遵循编码规范。

但名字起得是否够好，主要看是否还需要额外的解释。

很多程序员起名字习惯于采用面向实现的名字，比如，采用数据结构的名字。

很多没写好的程序有一些原因就是名字起错，把一些概念混淆在一起了。

想起好名字，就要学会用业务语言写代码，需要尽可能多地学习业务知识，把业务领域的名字用在代码中。

---

轻量级沟通

多面对面沟通，少开会。

会议中，每个人发言的时间一定是有限的。在有限的时间内，建议只说三件事：

• 我过去一段时间做了什么？

  与其他人同步进展，看事情是否在计划上，一旦偏离计划，请主动把它提出，这可能会涉及到是否要调整项目计划

• 我未来计划做什么？

  同步你接下来的工作安排。如果涉及到与其他人协作，也就是告诉大家，让他们有个配合的心理准备

• 我在过程中遇到了什么问题，需要请求帮助

  与其他人的协作，表示：我遇到不懂的问题，你们有信息的话，可以给我提供一下

---

可视化沟通方式

ThoughtWorks技术雷达 是由 ThoughtWorks 技术咨询委员会编写的一份技术趋势报告，每 6 个月发布一次。ThoughtWorks 的项目多样性足够丰富，所以它能够发现诸多技术趋势。因此，相比于行业中其它的预测报告，技术雷达更加具体，更具可操作性。

雷达图是一种很好的将知识分类组织的形式，它可以让你一目了然地看到并了解所有知识点，并根据自己的需要，决定是否深入了解。

通过创建图像、图标或动画等进行信息交流的形式，就是可视化（Visualization）。可视化有很多种不同的分类，我们最常用的应该是数据可视化和信息可视化。

很多做软件的人习惯于用文字进行沟通，一般在软件开发过程中，需要编写各种文档，但并不是所有的场景，文字都是好的沟通方式，所以，也会有很多人尝试着将可视化应用在软件开发过程中。

估计大多数程序员最熟悉的表达方式应该是流程图，如果你做过软件设计，可能还听说过 UML（统一建模语言，Unified Modeling Language）。如果使用得当，这种方式会极大地提高表达的准确性，降低其他人理解的门槛。

“可视化”应用在工作中的典型案例：看板。

看板，是一种项目管理工具，它将我们正在进行的工作变得可视化。这个实践来自精益生产，“精益”这个来自丰田公司的管理理念。精益的理念在软件行业已经非常流行了，很多软件开发实践都是从“精益”而来，看板就是其中之一。

它将工作分成几个不同的阶段，然后，把分解出来的工作做成一张卡片，根据当前状态放置到不同的阶段中，每个用户故事就是一张卡片。在实际工作中，每当一个工作完成之后，它就可以挪到下一个阶段，工作怎么算完成就是由我们前面提到的 DoD 来决定的。

如果一个人多线程工作，效果不会好，用“精益”的术语来说，我们应该限制 WIP（Work-In-Progress）；再有，如果待开发的卡最多，那就证明现在的瓶颈在于开发，而不是其它阶段。

---

持续集成

持续集成的关键点：快速反馈。

持续集成的诞生，就是人们尝试缩短集成周期的结果。

为什么要缩短周期呢？因为我们希望尽早得到反馈，知道自己的工作结果是否有效。

在自己的开发机上执行集成，就会比在 CI 服务器快。也就是说，执行同样的操作，本地环境会快于 CI 服务器环境。

持续集成中重要的一个提交纪律：只有 CI 服务器处于绿色的状态才能提交代码。有检查在运行不能提交，有错误不能提交。

所以，不能把检查只放到 CI 服务器上执行。

想做好持续集成的一个关键点是，用好本地构建脚本（build script），保证各种各样的检查都可以在本地环境执行。

一旦有了构建脚本，你在 CI 服务器上的动作也简单了，就是调用这个脚本。也就是说，本地检查和 CI 服务器上的动作是一致的。

每完成一个任务，在本地运行构建脚本，如果有问题，就修复；没问题，则可以同步代码。如果 CI 服务器上没有正在运行的服务，就可以提交代码了。

另外： CI 服务器一旦检查出错，要立即修复。

---

复盘

如果同样的问题反复出现，说明没有做好复盘。

复盘，原本是一个围棋术语，就是对弈者下完一盘棋之后，重新把对弈过程摆一遍，看看哪些地方下得好，哪些下得不好，哪些地方可以有不同甚至是更好的下法等等**。把过程还原，进行研讨与分析的方式，就是复盘**。

复盘时，站在另外一个视角，去思考引起这个问题的原因。这个时候，你不再是当事者，而变成了旁观者。你观察原来那件事的发生过程，就好像是别人在做的一样。你由一个主观的视角，变成了一个客观的视角。

用别人的视角看问题，这就是客体化。

回顾会议的主题，常分成三类：“做得好的、做得欠佳的、问题或建议”。

或者：继续保持、开始做、停止做、多做一些、少做一些”五类。

写事实，不要写感受。因为事实就是明摆在那里的东西，而感受无法衡量，你感觉好的东西，也许别人感觉很糟糕。

所有给出的未来行动项应该都是可检查的，而不是一些无法验证的内容。比如，如果行动项是让每个程序员都“更仔细一些”，这是做不到的。因为“仔细”这件事很主观，你说程序员不仔细，程序员说我仔细了，这就是扯皮的开始。

多问一些为什么。具体怎么问，有一个常见的做法是：5 个为什么（5 Whys） 。

不要用这些方法责备某个人。我们的目标是想要解决问题，不断地改进，而不是针对某个人发起情感批判。

定期复盘，找准问题根因，不断改善。

---

面向用户

产品经理无论要做什么，他都必须有一个立足的根基：为用户服务。

如果你了解了用户怎么想，你就有资本判断产品经理给出的需求，是否真的是用户需要的了。

把工作范围扩大，由听产品经理的话，扩大成倾听用户的声音。

不断使用自家的产品，会让你多出一个用户的视角。

在挑毛病找问题这件事上，人是不需要训练的，哪里用着不舒服，你一下子就能感受到。所以，不断地使用自家产品，你自己就是产品的用户，这会促使你不断去思考怎么改进产品，再与产品经理讨论时，你就自然而然地拥有了更多的维度。

无论是自己做用户，还是找机会接触已有用户，亦或是没有用户创造用户。只有多多听取来自真实用户的声音，我们才不致于盲目自信或是偏颇地相信产品经理。谁离用户近，谁就有发言权，无论你的角色是什么。

一秒钟变小白的能力，变成自己的客户，有意识地锻炼共情能力。

---

及早暴露问题

常见问题：发现自己可能搞不定任务的时候，选择继续闷头做，而不是把问题暴露出来，寻求帮助。

作为一个程序员，克服技术难题是我们工作的一个重要组成部分，所以，一旦有困难我们会下意识地把自己投入进去。但并不是所有的问题，都是值得解决的技术难题。

遇到问题，最好的解决方案是尽早把问题暴露出来。

比起尽早暴露问题，还有更进一步的工作方式，那就是把自己的工作透明化，让别人尽可能多地了解自己的工作进展，了解自己的想法。越往前做，给人留下的空间和余地越大，调整的机会也就越充足。而在最后一刻出现问题的成本实在太高，大到让人无法负担。

真正的挑战在于克服自己的心理障碍。很多人都会下意识地隐瞒问题，但请相信你的队友，大家都是聪明人，问题是藏不住的。

---

写文档

很多人回避写文档的真正原因是，他掌握的内容不能很好地结构化。

作为读者，我们读文档，实际上就是按照作者梳理的结构在走，因为呈现出来的内容，多数是已经结构化的，读起来自然会比较顺畅；而作为作者，没有人告诉你结构应该是什么样，我们必须创造出一个结构来，而这正是很多人不擅长的。

想要成为一个好程序员，有一个良好的知识结构是极其重要的。

将零散的知识结构化，有很多种方式，但输出是非常关键的一环。

输出的过程，本质上就是把知识连接起来的过程。自己以为自己懂的东西，当你真的需要把它按照一个完整的逻辑呈现出来时，那些缺失的细节就会冒出来，而补齐这些细节，一张知识地图就逐渐成型了。

输出的方式有很多，对于程序员来说，最常接触到的两种应该是写作与演讲。

读到很多书、很多技术文章，这都是别人通过写作的方式进行输出的结果。

而很多技术大会上，常常会有各路高手在台上分享自己的所得，这就是演讲的输出方式。

多输出，让知识更有结构。

---