微信号:wilddogbaas

介绍:野狗官方订阅号.这里有关于JavaScript、iOS和Android等前端技术干货,还有网络安全和性能优化的技术分享.

99%的人都不会问问题 | 怎样问出能得到很棒回答的编程问题

2016-07-22 22:00 Luke



✦ ✦ ✦ ✦ ✦ ✦ ✦ ✦


是否有过问了一个代码相关的问题但没有得到任何回复的情况?即使你得到了回复,在你得到有用的答案前,你们有没有来来回回多次地进行问题的澄清?


这样的情况经常会发生。


之所以会发生这样的情况,是因为你问的问题不够好以至于别人无法立即回答你。在这篇文章中,我会帮助你学习提出好的编程问题的艺术,这样你就总是能得到好的答案。


但是首先,在你得不到回复时,不要生气(或者觉得你自己不够优秀)。


 1   为什么人们不回答问题


能与你相信的相反,即使在他们很忙的时候,人们也确实愿意回答问题。许多专家无论何时都积极地通过email回答问题:有些人非常快地回答Github上的issue,有的人每天浏览Stack Overflow来帮助回答问题。


但是没人愿意花100%的时间在回答问题上。每个人都有自己做事的优先级。说实话,回答问题的优先级很低。责任在你,你应该提出别人能够快速理解和回答的问题。


那么,一个别人愿意回答的好问题是怎么构成的呢?


 2   一个好问题的结构


  1. 它很具体

  2. 它很清楚简洁

  3. 它显示你已经在这个问题上努力过了


其实并没有固定的结构。只要你满足了以上3条,你就可以提问了。


这里有个提问的例子,在回答这个提问前,我拖了一会(任何对你问题答案的拖沓都是不好的,因为回答者最后可能完全把你的提问跳过了):



让我们一起把这个问题分析下,看看为什么它没有马上被回答,有什么办法可以改进它。


首先,它不够具体。以下的三个地方如果更明确一点,会大大改进这个问题。

  1. 我应该评论什么?我怎么评论?我要向他证明我的东西么?他是在寻求帮助么?

  2. Accessibility怎么理解? Accessibility是一个很大的词,可以意味着很多东西。

  3. 我的scaling的技巧是什么?他到底是在特指哪种技巧?


第二,不够具体导致这个问题不清楚,即使我想回答这个问题,我也没法在不问更多问题的前提下回答。


第三,不知道他花了多少努力在:(1) 构思这个问题  (2) 尝试他所提到的方法。这里,不具体的提问体现出这家伙没有好好坐下来仔细构思这个问题。除此以外,在提问之前,他有没有自己试试那些scaling的方法?通常情况下,在没有亲手尝试前就提出一个宽泛的问题,对你一点价值都没有。


由于提问的模棱两可,我可以从27个角度来回答这个问题。从每一个角度来回答这个问题非常累人,说实话,我也不想这么做。


通常我会问一些澄清的问题来缩小这些角度。顺便说一句,提出这些澄清问题很蛋疼。许多人甚至不会回复我的提问,我的努力(多数)都进了他们的垃圾邮件。


注意:你不是总是要去问对方代码。这个例子中,我觉得他甚至不愿意开始去尝试我提到的方法因为他不知道那些方法是否scale(无论scale是什么意思)。


通过一些澄清的问题,我明白了他要的功能是人们可以在网页上放大缩小,同时,保持网页中元素的比例。


这里是怎么把这个问题变得更好的一种方法:

你好 Zell,

感谢你写的所有有关响应式排版的文章, 它帮助我xxxx.

我有一个困惑的问题。 当你使用em和rems的时候,如果有人在页面上放大缩小,你还能保证页面上元素的比例不变么?

更清楚一点,假设我的body部分的字号是16px,h1标题的字号是它的2倍,32px。h1标题的字号会永远保持body部分的2倍么(在页面缩放的情况下)?

谢谢, 出色提问者的姓名


让我们一起来分解下这为什么是一个好问题:


首先,这个问题以“感谢”开头, 就使这个问题变得比较友好。它同时让(回答者)更设身处地,以便于他们回答问题。


第二,这里只问了一个具体的问题。它很清晰明确。你马上能明白提问者在问什么,所以这个问题就变得非常容易回答。


第三,它太清楚了。不同的人对同样的单词可能有不同的理解。如果需要,你可以提供些例子来使问题变得清楚,避免问题中引人误解的地方。这样有助于马上得到正确的答案。要知道,清晰的问题总是比简洁的问题更好。


最后,这个问题显示出他已经努力过了。把一个问题提取成一个具体的问题是很难的。愿意去这样做已经是一个加分项了。它同时显示出提问者已经尝试过了(至少在他的脑子里)。人们愿意帮助那些努力的人。他们知道他们回答问题的努力不会白费。而我也是这么觉得的。


刚才我举例的问题是很模糊的、需要澄清的。但是如果你有一个编程相关的问题需要回答者看你的代码,你应该怎么做呢?


 3   让回答者看你的代码


果你写代码,那么你已经做了一些功课了,恭喜你


你仍然可以用上面提到的一样的建议来帮助你。重申一次,这些建议是:

  1. 问题要具体

  2. 问题要清晰简洁

  3. 让他们看到你做了什么


这里我们会遇到一个有趣的困境。当人们问与编程相关的问题时,经常遇到这样的情况,就是他们展示了太多他们的代码。


这里举例一个我收到的提问:


好,哪里不对了?


首先,它不够具体。问题在哪?他有个demo,这自然很棒,但是这个demo太大了!同时,这个问题来自一个买了我的书Susy的人,所以我在想这个问题跟Susy有没有关系。另外,这个问题描述得也不是很清楚。


当你思考这个问题有多具体时,想想对于回答者来说,你怎么能使这个问题变得超级清楚。截个屏,画个图,拍个小视频。怎么能让回答者容易回答,你就怎么来。


其次,代码在哪呢?我想不看代码的话,我什么都做不了,对吧!?😄


当你给别人看代码时,注意就给别人看跟问题相关的那一部分。不要给他们看全部的代码,因为那太吓人了。你会想都不想就给别人debug 1000多行的css代码么?估计不会吧,我也是。


如果你需要给别人看代码,确保回答者可以方便地查看和编辑你的代码。即使你提问的人比你厉害很多,他可能也没法不debug就找到出问题的代码(我知道有些特别厉害的人可以,抱歉,我不行)。


对于前端/静态页面的问题,你可以很容易地用Codepen编写你的样例。如果你不知道怎么用Codepen,你一定要看一看Chris的这个视频,他在这个视频里一步步讲解了Codepen的基础知识。这个视频很老了,但是基本原则还是一样的。


如果你不能用Codepen,你应该找到另外的方法,使回答者可以快速查看、编码你的问题。Git repo是另一个非常棒的方法。


如果你Codepen跟Github都不能用(说实话我真想不出为什么),发一个zip文件过去。这总比什么都没有好。


可能你已经注意到了,最基本的原则是你要显示出对回答者的时间的尊重。把你的问题变得具体、清晰和简洁。尊重回答者的时间,那么你得到一个非常棒的回复的几率也会变大。


 4   不要不好意思问问题


会有问题是很正常的。如果它困扰你,你就去问别人,哪怕你觉得这是在浪费别人的时间。


人们是很愿意帮忙的。多数情况下,他们可能已经见了很多次同样的问题。他们甚至可以想都不想就告诉你正确的解决方向。我就经常让别人看我的博客;) 通过这个方法,回答者不会浪费时间,你也可以更快接近正确的答案,双赢。


如果英语不是你的母语,你也不用担心。问问题时,你不需要很时髦的词汇。实际上,简单的词句反倒比复杂的词语来得好。别理对你的英语很苛责的人,他们的意见根本不重要。


 5   在正确的地方提问


可以在email,论坛,Stack Overflow或者任何你能想到的地方提问。不论在哪里,重点是你要在一个回答者觉得最舒服的地方提问。


不同的人有不同的喜好。有的人喜欢你通过email提问,有的喜欢twitter,还有的也许喜欢面对面?


就我个人而言,我从今天起就要转变我回答问题的方式。如果你想向我提问(有关设计、前端、后端、生活等等),请到Github repo上并提出一个issue。我会回复的。


我想通过Github来处理编程问题的原因是:

  1. 通过这个方式,你的问题不会淹没在我的收件箱里。

  2. 我(可能)已经回答过你的问题。你可以在Github上容易地搜索他们。

  3. 它使我能方便地进行搜索,并向别人指出正确的答案,而不是每次都对问题进行新的回复。

  4. (最后这点炒鸡棒)。如果你问我问题,我就有新的东西在我的博客里讲(通过拓展对你的回复)。目前,所有的东西都淹没在我的email里,导致我每周都要想些新的主题来写。所以,来Github提问吧!


 6   总结


前,我总为能回答我邮箱里的每个问题而自豪(即使是非常模糊的问题)。我通常会问澄清的问题,直到我没什么可说。


这太累了。我花在回复email上的时间多过我做自己喜欢的工作的时间。说句心里话,我写这篇文章有2个理由。(1) 帮助你提出更好的问题(2)减少我自己干的活。


所以说,如果你的问题还没有遵从我在这篇文章里提到的原则,我会把这篇文章告诉你,直到你修改好问题为止,怎么样?


除此以外,你自己也清楚提出好问题的好处,这就不用我说了吧 :)


✦ ✦ ✦ ✦ ✦ ✦ ✦ ✦


文:Luke Page  原文:http://www.zcfy.cc/article/how-to-ask-good-coding-questions-that-get-great-answers-706.html





点击“阅读原文”,看更多

精选文章

↓↓↓

 
野狗 更多文章 Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE 除非你是BAT,前端开发中最好少造轮子 10倍提升应用性能的10个建议 如何设计和构建你自己的JavaScript代码库:提示与技巧 HTTP, HTTP2.0, SPDY, HTTPS | 4种网络协议的渊源与发展
猜您喜欢 陌生网络里的恐惧(第一篇) 从LAMP到LNMP 女排夺冠困扰我的两大难题 TabHost中控制activity生命周期---过时的控件 拜读:大神程序员为什么牛?