程序员如何高效和同行交流

你是否在工作中经常遇到这种对话:

A:你给我的接口为啥访问不通啊?

B:确定是 POST 方法吗?参数 foo 加了吗?

A:加了啊?

B:我看下。

5分钟后。

B:你没加 application/json 啊。

A:还是访问不通啊。

B:我看下。

5分钟后。

B:URL 后面不能加 / 啊,不需要加。

A:……

B:……

本文介绍一些如何避免这种无意义的对话的方法。个人认为,写在简历里面的“沟通能力强”并不是一个软技能,而是一个硬技能。不是说话啰嗦,敬词用的多就是沟通能力强,而是用最少的话把信息描述清楚没有歧义,这要求理智和健全的身心,以及相关的工具和背景知识。


糟糕的沟通:紧张的描述 “我的 xxx 怎么不 xxx?”  “xxx 了怎么办?” 别人很难回答你的问题,必须继续追问你几个回合之后才知道你想表达什么。

有效的沟通:以不让别人追问为原则,描述清楚自己遇到的问题,所处的运行环境,如何复现。能够让别人复现你的场景非常重要。举个例子,前端的问题可以用 jsfiddle 复现,后端问题可以提供一个 docker 命令。


糟糕的沟通:截图一大片代码,中间包含某个报错。并问:为啥我的命令的结果是这样?

有效的沟通:贴出来这个命令一个结果的文字版本,然后提问。

除非是 GUI 方面的问题,一般人都会憎恨从图片中抄写代码。贴 URL 、代码以及转发,要优于贴图片。

如果一些 IM 工具对代码的格式化不好,(比如微信和钉钉),可以将代码写到 Gist 然后贴 Gist 的链接。甚至传文件也比截图要强。

有时候你要将别的群聊内容转发给另一个对象的话,尽量使用 IM 的转发功能,这样别人就可以知道上下文,知道前因后果。如果公司特别大,你经常遇到去问一个人A,A甩手让你去问B,B又让你问C的话,转发功能就比较好用了。

无论是在网络论坛,还是聊天,亦或是邮件,都应该善用引用能,提供原文的地址要优于复述原文。


糟糕的沟通:文档中写:接口参数是xxx,URL是xxx。

不要指望你这么描述能够让一个 HTTP 接口没有歧义。更糟糕的是,我见过 HTTP 的文档上就贴了一个 Java 的 Class,并且里面的注释类似这样: private String button; // 按钮

有效的沟通:在写文档或者 IM 工具中,尽量用 cURL 或 HAR 交流参数信息。如果是 HTTP API 文档,在有条件的情况下,可以搭建像 Swagger 这样的 API 平台。向接口的提供方描述问题的时候,不要说我使用的xxx怎么不行?可以直接贴给对方你的 cURL 命令,这样它们就知道你发送的请求了。现代的浏览器,以及 postman insomnia 这种 API 工具,都支持将 HTTP 请求导出到 cURL。

除了 HTTP,其他的交流也可以使用命令。比如遇到磁盘问题,可以将 df 或者 mount 命令之类的作为信息提供给运维同事。命令优于口头描述。


糟糕的沟通:在吗?

有效的沟通:直接提供你的问题,尽可能描述对方可能用到的所有的信息,不让别人追问。

这一条尤为重要,否则可能会被同事当做神经病。

程序员如何高效和同行交流”已经有5条评论

  1. 命令优于口头描述。 深有体会,不同同时的背景完全不同,有时候说一些模糊的要求,远不如直接给条命令来的痛快直接

Leave a comment

电子邮件地址不会被公开。 必填项已用*标注