最后更新于:2020 七月 27日 , 星期一 , 23:46 晚上

最最重要的前提📌

回答问题首先得肚子里有货,切忌不懂装懂瞎指导,坑害小白(包括当前问题的解决、理解以及将来发展……)。
BTW,我不是程序员,但世界上大部分 Method 都有相通之处💆‍♂️

介绍

一个程序员在学习的过程中会遇到各种问题,我们会在提问中成长。终有一天,我们也会主动或是被动地解决别人的问题,这个时候,拥有技术的实力不代表能回答好一个问题,这也需要技巧。

回忆一下别人是怎么回答你的问题的,在众多你问题的回应之中,有没有答非所问、语句难懂,又或是折腾了半天也无法解决的?如果这不是你提问方式或是自身操作的问题,那么一定是被提问者一定不太擅长回答。是的,回答也需要智慧。

如果你缺乏回答的技巧,说不定也会在不知不觉中犯下可笑的错误。这不仅会浪费你的时间,也一定会浪费提问者解决问题的宝贵时间。

那么,如何有效率地回答他人的问题呢?

回答问题之前

对方提问的途径

首先,你要确认你是在哪里收到这个问题的,也就是说,要确认提问者是通过什么途径向你提问的。

可能是在论坛上求助发帖、在群聊/聊天室内发送问题,这样的问题是面向大众的,并没有针对性,所以如果你不想回答可以直接当做没看到。这个时候,你和提问者是平等的网友/群员。

也有可能是通过即时通讯软件的私聊窗口、电子邮件、面对面交流等方式,这样的问题的提问对象是只针对你(被提问者)的,对方大多是出于对你的信任和尊重才会向你寻求帮助(当然不排除病急乱投医的情况,这里就不讨论这个了),这时对方是直接地有求于你,但你仍然应该以互相尊重的态度对待。

明确提问者的身份

这里所谓的“身份”,应该包含以下几个因素:

  • 是否熟识(陌生人/朋友?)
  • 是否与对方有上下级关系(同事/领导?)
  • 对方的技术水平(小白/入门/精通?)

这是比较重要的因素。如果你与提问者熟识,那么你可以尝试回忆对方常犯的错误或是一些不太好的习惯,看看这个问题是不是由这些因素造成的;如果对方是你的领导或是形式上地位高于你的人,那么语气最好应该放恭敬一些,即使是对方有求于你;如果了解了对方的技术水平,我们可以决定在描述中该不该使用比较深奥的专业术语,可以了解对方到底有没有能力解决这个问题等等。

简要阅读问题

先别急着解决,简单扫一眼问题,看看这个问题是不是:

  • 非常基础 / 简单
  • 能够容易地在搜索引擎上找到答案
  • 有人曾提出过解决方案
  • 在原作者提供的文档中有提到(如果是使用开源项目)

如果这个问题的确满足以上的条件,那么你完全有理由不浪费时间,不亲自回答这个问题。你可以直接告诉对方,这个问题在哪个地方有确切的答案,或许一个链接能让对方更快解决问题。

当然,还有一个很重要的问题需要确认:对方是否有能力在你的描述下解决问题。如果这个问题很麻烦,比如:需要在源文件中进行修改,要完全重写代码的结构,而对方基础薄弱,那么你就可以直接奉劝对方放弃;如果情况比较紧急的话,你也可以直接动手帮助对方操作,利用文件传输或是远程控制。

回答问题之时

深入分析

这是回答问题最重要的环节了,既然你已经决定要帮助对方,那么对方既是求助者,也是委托人,你需要把这件事当做你的工作来认真对待。这个时候,如果是私聊这样一对一的求助,记得先给对方发一句“好的,我看看”之类的话,表明你打算帮助解决这个问题了。

首先,回答一个信息技术相关的问题,大多时候你应该要了解这些信息:

  • 对方的开发环境以及版本
  • 对方所使用的工具
  • 程序抛出的报错信息(或是日志)
  • 实际的效果和预期的效果

你要了解问题到底出在哪,如果是一个错误,应该先从报错信息和日志了解问题所在,然后找到相关的源代码,作为一个程序员应该是常识。若源代码无误,没有报错,考虑一下兼容性的问题,注意环境和版本,如果不费时间的话,不妨自己重新实现一下,看看是不是一个 bug,或是什么地方产生了冲突。

作为一个能被提问的程序员,基础肯定是没有问题,如何分析问题应该不用多说。

但请注意,理解了问题之后最好再从头读一遍问题,避免遗漏疏忽导致误解,闹出答非所问这样的笑话。

符合语法的语句

语文再不好,人话肯定是会说的。只要用条理清晰的语句简洁地描述解决方案就好了,但简洁归简洁,必要的地方还是不能省。也要注意语句会不会产生歧义,要注意,你是在描述解决方案,而不是在写文学作品。

专业术语

如果对方有一定的基础,请尽可能多地用上专业术语,这样能使表达更加准确、简洁有力。这个时候,不需要过多地考虑对方是否有正确理解这个词,只要确认你有正确用好这个词就行了。

有时候,同一个事物会有多种表达,例如 inline element 既可以叫做行内元素,也可叫做内联元素。这个时候我们要尽量选择能让对方快速理解的词汇,通常也就是比较大众化的表达。“行内元素”比“内联元素”更加常用,要用到的时候,选择“行内元素”会让表达更加清晰。

在必要的时候,使用英语名词能更准确地表达自己的意思,因为许多的名词都是从英语翻译过来的,难免会产生歧义,例如前端设计中的 Flex 布局,也不会有多少人将它称作“弹性布局”的吧。善用英文不仅能使表达更加准确,还更加简洁有力。

注意标点符号

有不少的歧义都是标点符号闹出来的,想想为什么会有“牛津逗号”这样的存在。你不一定要百分之百准确地用好句子里的每一个标点符号,你只需要保证这句话不会被人理解成别的意思,你甚至可以在一句话中只使用逗号和句号。

如果你实在嫌弃标点符号烦人,觉得不停切换输入法就是为了打出正确的符号很麻烦,为什么不试试用空格或换行来代替它们?尽管我不太推荐这种做法。

减少反问

不少的提问者也不懂得提问的智慧,它们总给不出完整的信息让被提问者进行分析,常常会需要反过来询问它们以获得更多的信息。我想这也是为什么不少的 GitHub 仓库都会给 issues 写一个默认的格式,就是为了让提问者尽可能提供完整的信息。

你也一定会遇到需要反问的时候,但是在很多时候这是非常耗费时间的,因为基础差的提问者常常需要你来向他们解释你想要的信息是什么、在哪里,而对方或许也在等待你回答的同时自己寻找答案,相对于对方来说也不太友好。所以,要尽可能减少反问的次数,可能的话,一次就把对方没有提供的信息说出来,对双方都比较友好。

基本的礼仪

尽管对方是有求于你,但你最好也要平等地对待对方,做到互相尊重。不需要特别注意使用敬语,因为从某种角度来说,该被尊敬的人是你而不是对方,但也不该贬低,哪怕是玩笑。

请避免在回答的时候说出“这么简单的问题都不会?“、”答案明明就很明显“这样的话,如果你不知道怎样委婉地表达,你可以直接给对方有相关资料的网址让他找到答案,而不是来上一句嘲讽。

解决问题之后也要及时回应对方的道谢,“不用谢” “小意思”之类的话应该都不难吧?如果对方因为自身能力弱,在求助过程中造成了一些麻烦,向你道歉,也应及时回应,这些感谢语就不一一列举了。

礼仪无需多讲,总之做到就好。

必要的补充说明

有时候,问题解决后会引发一些其他的小问题,特别是某些程序的 bug 的临时解决方案,这个你需要说明清楚,免得麻烦对方发现之后再来问一次。

某些功能实现之后,日后需要经常更改相关代码,也应交代清楚。

总之需要对方注意的,都请帮忙帮到底,不要因为说明的疏忽给别人造成了其他的麻烦。

如何有礼地拒绝

当你收到他人的问题,你可能在忙,或是因为心情不好等其他原因不愿意回答或帮助,也有可能是自己的能力不够,所学内容没有涉及到那一方面,无法回答,这时应该婉拒

首先要如实地交代不能回答的原因(如果这个原因中涉及个人隐私,可以用万能的“我在忙”代替),同时也不能显得太过敷衍,谁知道暗地里对方会怎样评论你呢?

如果可以的话,可以给对方推荐其他有能力的大佬,或是可能有相关资料的网站/文档,让对方找到一个方向,更快地解决问题。

最后,尽管没有多大道歉的必要,但请多说一句“对不起”。

如果问题还是没解决

通过你对问题的分析所提供的解决方案也不一定能解决问题,这有很多方面的原因:对方执行上的失误、方案本身的问题、(可能)问题的不可解决性等。但在彻底找不到出路之前都不要放弃。

亲自动手,通过远程控制或者自己搭建一个环境重新实现,这种方法能有效地解决可被解决的问题。根据你自己的做法或许能容易地找到对方的漏洞和错误,但注意了,这种方法仅限于迫不得已的时候,不然很麻烦、浪费时间还容易发生意外。它只是有效而不是有效率。

如果还是没有解决,尝试从细微之处找问题。例如本地缓存之类的问题,这很简单,而且是你最开始就应该注意的问题,但说不定你就漏掉了呢。此外,重启和重装也是一个你早就该试试的方法。

如果到最后你还是没能帮助对方解决问题,浪费了对方的时间,一句“对不起”总是好的。通常这样的问题在搜索引擎或是某些网站上已经难以找到答案,你可以给对方推荐一些更厉害的大佬,说不定别人就解决了呢?

搞砸了怎么办

如果你在描述解决方案或是直接帮助时因为操作失误等原因,给对方造成了一定的损失,例如:数据丢失、服务器过载等问题。尽管这种情况不太常见,但如果遇到了,你应该负起责任。

首先,永远不要吝啬你的“对不起”。这种情况下你第一个能做的事情就是道歉,主动承认你的错误,描述清楚意外发生的原因,不要让对方觉得你是在开玩笑。

然后,尝试补救。就像你小时候一不小心打碎了别人家小朋友的玩具,无论结果怎样,都还是要修锅的,就算不能彻底修好,但也算是在展示你的态度了。

到最后,如果真的给对方造成了不可挽回的损失,要怎么赔偿还是要看对方的想法了。

报酬

你帮助对方解决了问题,理应获得一定的报酬。但对于网络上更多是发自善心的帮助,不应强行索要报酬,不要认为你帮了对方一个小忙对方就该砸你钱,何况这钱也不会多,最多算是欠你一个人情。不过,如果对方真的主动想要用金钱当做感谢的话,也不用拒绝,因为这是你应得的。

题外话

顺便记录一次贻笑大方的经历:

@冼仙

忍不住纠个错:in the wayin 不能漏掉

@Eltrac

想想为什么「提问的智慧」原文里没有介词 in(http://www.catb.org/~esr/faqs/smart-questions.html )因为这根本不是在做状语。我想你应该见过电影 / 游戏里的人物称呼自己的时候,为了强调自己的身份,会这么说「FLOWEY the FLOWER」(这是 undertale 里小花的台词),the 前面的是 TA 的常用名,the 后面的是他的身份。那么「Amily the girl」,就是说「我叫 Amily,并且我在强调,我是一名女孩」。这里的「How to Answer Questions The Smart Way」你可以看作并列的两部分,这是在说「这是一篇教你如何提问的文段,并且我再强调这是一种聪明的方式」


 目录

既见君子 云胡不喜