关于程序员:如何提出一个高质量的问题

封面图源自：Pexels

前言

看到题目的一瞬间，你或者在想“什么样的问题算是好问题？”，在思否，每天或多或少都有十几个（休息日除外）新的问题被提出来，而这外面充斥着不少的“品质”问题。

如果你有曾读过《发问的智慧》这本书，那你就应该晓得该如何去提出一个问题，本文也算是对这本书的一个衍生补充。

上面，我将以我的视线，带你提出一个好的问题。

真的须要提出这个问题吗？

在发问之前，你应该先应用 Google、百度、必应等搜索引擎尝试寻找答案，因为在大部分时候，你能遇到的问题，其他人可能曾经遇到过了，而后依照其中的解决方案进行解决，问题或者就解决了。

比方：Vue 路由的实现原理？– SegmentFault 思否

个别能够形容进去的问题，或者更加容易检索，没准你花半个小时搜寻一番，你的问题就曾经解决了。

而如果你抉择间接提出一个问题的话，大概率在三十分钟内得不到解决。

如何检索问题，大部分时候比拟容易，然而遇到一些非凡状况，就变得麻烦了，比方咱们在运行命令的时候出错了，那么可能会打印进去无比简短的错误信息，而且基本上都是英文，从中提取出有用的信息至关重要。

举个例子，就像 上面这一堆错误信息。

D:\workplace\newcodebdc\back> npm install
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR!
npm ERR! While resolving: vue-antd-jeecg@2.0.0
npm ERR! Found: webpack@4.46.0
npm ERR! node_modules/webpack
npm ERR! webpack@"^4.0.0" from @vue/cli-plugin-babel@3.12.1
npm ERR! node_modules/@vue/cli-plugin-babel
npm ERR! dev @vue/cli-plugin-babel@"^3.3.0" from the root project
npm ERR! webpack@"^4.0.0" from @vue/cli-plugin-eslint@3.12.1
npm ERR! node_modules/@vue/cli-plugin-eslint
npm ERR! dev @vue/cli-plugin-eslint@"^3.3.0" from the root project
npm ERR! 3 more (@vue/cli-service, less-loader, sass-loader)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! vue-loader@"^15.7.0" from the root project
npm ERR!
npm ERR! Conflicting peer dependency: webpack@5.73.0
npm ERR! node_modules/webpack
npm ERR! peer webpack@"^5.0.0" from css-loader@6.7.1
npm ERR! node_modules/css-loader
npm ERR! peer css-loader@"*" from vue-loader@15.10.0
npm ERR! node_modules/vue-loader
npm ERR! vue-loader@"^15.7.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See C:\Users\MaxThunder\AppData\Local\npm-cache\eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:

这时候咱们只须要拷贝这部分错误信息，先进行翻译，尝试去了解为什么错，如果不能了解，就到搜索引擎进行搜寻，大多数状况下，你都能失去答案。

当产生谬误的时候，咱们应该先在报错信息中寻找一个关键字 Error，大部分时候，呈现这个关键字的时候，紧随其后都会打印出具体的谬误，局部的还会打印出一个谬误的 CODE，比方 MySQL 的报错，你顺着这个 CODE 加上软件名字，没准就能检索到。

如下面的外面，充斥着 ERR，这就有很多谬误的，一眼也无奈分辨，如果你复制的翻译后，大略就能晓得，是“xxx 依赖不能解析”，并且在前面还提供了一段 fix(修复) 办法，让你尝试在命令前面加上 --force 或者 --legacy-peer-deps 进行重试，或者你执行后问题就解决了，你也就不再须要提出一个问题了。

提出问题

适合的题目

大部分社区，都是以题目的模式在列表展现进去的，像 思否 这种还会在列表展现标签。回答者并不是机器人，大多数时候，回答者并不会关上所有帖子进行查看，起一个适合的题目更能让回答者判断这个问题是否在本身的解决范畴之内，从而点开。

不好的例子

• 求求大佬解答求求大佬解答 – SegmentFault 思否

好的例子

• 当初常见的不同 app 相互“监听”用户需要是怎么实现的呢？– SegmentFault 思否
• 编写一个 js 算法，用一次循环将数组中呈现 2 次或者以上的值删掉 – SegmentFault 思否

高质量的问题形容

在你的问题被解决前，你须要做的最终重要的一件事，就是让回答者晓得你在问什么，否则他人很难给你回答。

正如思否的发问模板一样：

• 你遇到了什么问题？
• 你的预期是什么？
• 你的环境是什么（运行的软件版本、操作系统）？
• 你做了哪些工作？
• 呈现问题的代码

依照下面的规定，形容你的问题，让回答者能更加清晰的晓得你遇到的是什么问题，除此之外，你可能还须要依照提供一些额定信息，来帮忙回答者更快的帮你解决问题，毕竟帮回答者节约工夫，也是给你本人节约工夫。

学习应用 Markdown 语法，这花不了你多少工夫，顶多十分钟，然而终生受害。

• Markdown 根本语法

1、不要应用图片上传代码，当初探讨的社区，根本都反对 Markdown 语法，花上少许的工夫，学习一下如何贴代码，这样回答者也能够间接把代码复制到本人的环境上运行，疾速复现 / 定位问题所在。

应用 3 个 ` 符号（键盘左上角，ESC上面，数字 1 后面，英文状态下输出），前面紧跟语言类型，最初再以新起一行，写下三个 ` 即可形成一个代码块。

```js
alert('Hello')
```

最终将显示为如下成果。

alert('Hello')

2、尽可能提供有用的信息

在数据库相干的问题中，尤为常见，大部分人发问的时候，都是间接把数据截图和本人写的查问语句截图发上来了。

因为 SQL 自身就是形象的，尤其是简单的 SQL，都要进行测试能力合乎预期。

这就大幅升高了回答者的趣味，尽管当初 OCR 技术曾经足够弱小，可能能够辨认进去，但有时候还会要修改才行，而且，这类问题，大部分都是跟数据打交道，重要的就是数据呀，你什么都不提供，他人只能远而观之。

对于 SQL 类的发问形式，该当附上建表语句、数据填充语句、以及你本人写的查问语句。
对于建表语句，你能够应用 show create table 表名称; 来取得。

对于数据填充语句，以 MySQL 为例，你能够应用 mysqldump 这个工具导出，然而这可能简单了一些。然而当初一些 SQL 管理工具，都提供了图形化的导出为 insert 语句。

而你要做的这些，只须要破费你几分钟的工夫。

举个例子：

# 建表语句
CREATE TABLE IF NOT EXISTS `myTable` (`id` mediumint(8) unsigned NOT NULL auto_increment,
  `name` varchar(255) default NULL,
  `score` mediumint default NULL,
  `sex` mediumint default NULL,
  PRIMARY KEY (`id`)
) AUTO_INCREMENT=1;

# 数据插入语句
INSERT INTO `myTable` (`name`,`score`,`sex`)
VALUES
  ("Abdul Stanley",143,2),
  ("Chaney Pickett",62,2),
  ("Keelie Lindsey",99,2),
  ("Rae Hartman",146,2),
  ("Nevada Ward",72,1);

他人在拿到后，就能够不便的在本人的环境上进行解决了，你可能还须要提供 SQL_MODE 信息。

除此之外，还有就是你所运行的 MySQL 版本了。

当然，有时候咱们的数据可能存在敏感信息，请肯定要记得脱敏后公布。

你也能够应用一些数据构建工具来构建数据跟你构造类似的数据，比方：generatedata

或者：mockaroo

回绝 XY 问题

对于 X -Y Problem 的意思如下：

1）有人想解决问题 X
2）他感觉 Y 可能是解决 X 问题的办法
3）然而他不晓得 Y 应该怎么做
4）于是他去问他人 Y 应该怎么做？

简而言之，没有去问怎么解决问题 X，而是去问解决方案 Y 应该怎么去实现和操作。于是乎：

1）热心的人们帮忙并通知这个人 Y 应该怎么搞，然而大家都感觉 Y 这个计划有点怪异。
2）在通过大量地探讨和节约了大量的工夫后，热心的人终于明确了原始的问题 X 是怎么一回事。
3）于是大家都发现，Y 基本就不是用来解决 X 的适合的计划。

X-Y Problem 最大的重大的问题就是：在一个基本谬误的方向上节约别人大量的工夫和精力！

举个 🌰

Q) 我怎么用 Shell 获得一个字符串的后 3 位字符？
A1) 如果这个字符的变量是 $foo，你能够这样来 echo ${foo:-3}
A2) 为什么你要取后 3 位？你想干什么？
Q) 其实我就想取文件的扩展名
A1) 我靠，原来你要干这事，那我的办法不对，文件的扩展名并不保障肯定有 3 位啊。
A1) 如果你的文件必然有扩展名的话，你能够这来样来：echo ${foo##*.}

• X-Y Problem | 酷 壳 – CoolShell

帮忙回答者

在发问的时候，你能够多为回答者思考一些，比方通过一些在线服务，让回答者无需在本地环境上操作。

比方后面提到的数据库问题，咱们就能够应用 db-fiddle 来创立一个在线的 MySQL 运行环境，填写实现后点击 Run 确认 OK 后，再点击 Save 将会为你生成一个惟一的链接地址，当初他人关上这个链接，就能够在这下面间接编辑操作，不便了许多。

除此之外，像前端还能够应用

• CodePen: Online Code Editor and Front End Web Developer Community
• jsfiddle

这俩个都是国外的服务，可能比拟难关上，你也能够抉择国内的：

• 小闪电 – JSRUN 能够用手机写代码的 JS 在线编辑器网站

如果你的问题比较复杂，你可能还要思考提供一个「最小的可重现示例(Minimal reproducible example)」将其提交到 Git 服务，以提供给回答者。（☹️ 我想个别也不会简单到这个水平）

简单状况

还有一个问题，就是问题很小，然而代码很多。

常见于现代化前端的 CSS 问题，很多时候，问题是在我的项目或者某个组件中产生的，而即使是你提供了这个组件的代码，回答者也不能很好的复现问题，比方你的 DOM 可能是由数据渲染进去的。

这种状况，发问的时候，就应该把渲染后的后果 + 可能复现的起码的代码贴上来，这样更容易复现问题。

或者，能够应用一些浏览器扩大，把页面保留成单个 HTML 文件，上传到 免登录 / 注册的网盘 或者 Git 上。

比方 SingleFile，这个扩大就能够把网页所有内容保留成一个 HTML 文件，从而让回答者更加容易复现问题。

（当然，你也应该尽可能的提供原始代码）

gildas-lormeau/SingleFile: Web Extension for Firefox/Chrome/MS Edge and CLI tool to save a faithful copy of an entire web page in a single HTML file

Playground 或者 Sandbox

对于一些冷门点儿的语言，下面的这些工具，可能笼罩不到，然而你也能够尝试搜寻 语言 Playground，大概率能够找到一些能够在线编辑、运行、分享的服务，比方 Laravel playground。

保护好你的问题

很多时候，我都能在不同的社区看到同一个问题，毫无疑问，这个问题也是同一个人提的。

当然，多个中央就多了一分解决问题的机会，然而这些提问者往往都少有去“保护”本人的问题。

保护一个问题，往往比提出一个问题，更为重要。

1、及时回应 / 补充你的问题，有些人可能是第一次发问，脱漏了一些货色，有时候就会有人揭示你，须要补充哪些信息，请及时处理。像思否，默认状况下就会邮件告诉到你。

2、与回答者沟通，如果你的问题形容的不是那么完美无瑕，或者回答者了解偏差导致给出了谬误的答复，你应该及时的跟回答者进行沟通，而不是忽视他人。

这样也能够让其余回答者晓得具体的状况，对于我集体而言，如果一个问题，提问者本人没有保护这个问题，那么即便我有解决方案，我也不会抉择去答复。

3、不要反复发问，当你的问题几个小时或者一两天过来之后，依然没有人答复，请不要尝试再反复发问，因为很有可能不是他人没看到，而正是因为后面的种种原因叠加。当然，也有可能你的问题太过深奥，无奈给你答复。你还能够尝试邀请一些人进行答复。

4、抉择适合的答案，当你的问题被解决后，应该抉择帮忙你解决问题的人的答复标记为答案。这样也能够很好的帮忙其他人在遇到这个问题的时候，及时找到正确答案。

5、找到解决方案后该当附上，如果答复外面的都不能解决你的问题，最终你本人解决了，也应该附上答案。

6、同步解决方案，正如后面提到的，很多人都会在 N 个论坛收回同样的发问，而往往可能只是其中某个论坛的回答者解决了问题，而其余论坛则未解决。作为提问者，你应该像你当初提出问题那样，把正确的答案同步到你已经收回过这个问题的中央，为后来者提供便当。

你做了什么？

除了下面的以外，提出一个问题的前提是，你应该尽可能在本人的能力范畴内去尝试解决他，比方通过搜索引擎检索、尝试已有的计划、编写相应的代码，或者在这些过程中，你的问题就曾经解决了。

好的 🌰

• 编写一个 js 算法，用一次循环将数组中呈现 2 次或者以上的值删掉 – SegmentFault 思否

写在最初

• 以上论点仅为个人观点，如果有有余或谬误，还请不吝赐教。
• 你还能够点击文章中的起源链接，理解更具体的内容。
• 如果文中的内容进犯到了你得权利，请与我分割解决。

参考

• X-Y Problem | 酷 壳 – CoolShell
• Markdown 根本语法 | Markdown 官网教程
• How-To-Ask-Questions-The-Smart-Way/README-zh_CN.md at main · ryanhanwu/How-To-Ask-Questions-The-Smart-Way
• 对于 Markdown | Learning-Markdown (Markdown 入门参考)