提问与回答的智慧

翻译

bestechshare 2022-12-26 14:07:48

文章标签 数据库 IT SQL 文章分类 运维

1.1 前言

提问也是有智慧的，回答也是有智慧的，没错，今天就整理下啄木鸟社区的提问智慧，给关注思想的朋友们分享下；

其实不只是在论坛我们应该考虑，在生活中我们也应该有这样的思考！

1.2. 菜鸟提问需知

提问与回答的智慧_数据库

提问与回答的智慧_数据库_02

不要大喊大叫
使用一个好读的呢称
不要抱怨
语气请低调
请帮助他人
尊重他人

大喊大叫。特别是在QQ群里，使用过大的字体，过于鲜艳的颜色，都会严重影响阅读。本来QQ默认的窗体尺寸就小，你放一堆二号字上去，何况又是鲜红或嫩绿的二号字，让人怎么读？技术交流首先要保证消息的可读性，不要没事儿走视觉系。要知道每天坐办公室啃代码的老家伙们骨子里跟非主流艺术青年八九是不搭界的。黑色或靛蓝等传统的书写颜色可以让人舒服的阅读。
使用一个不好读的ID。这一点可能不太容易被人理解。然而如果你的ID别人都没办法念出来，大家就很难给你一个私密的回复。与其说是技术原因，更多的是心理因素。理由同上。不要指望每天坐办公室的老coder会跟你一样喜欢玩儿非主流视觉系。事实上靠谱的老程序员们往往跟这帮子家伙很不搭界。至少他们进入编码的心理状态时，是非常不喜欢看到一个花里胡哨的家伙跳出来在他面前画火星文。我从来没见过哪个靠谱的家伙顶着一个火星文ID在IM上写一堆鲜红嫩绿的二号字初号字。这些人最多也就是在QQ或MSN的签名上放几个表情而已。我曾遇到一个非常悲惨的实例。有个朋友多年来一直因为ID的问题在我们这个小圈子里被人BT，事实上他的名字一个火星文都没有，甚至也是一个合乎文法的名词词组。然而这个名字非常奇怪，念上几遍就会让人有想去抽他的冲动。于是大家不约而同的对他进行疯狂的BT。好在这位兄台有非常强健的神经，就像踩不死的小强一样生存了下来，并且在这种互相精神攻击的恶劣交流状态下学习到了很多东西。他的顽强还表现在工作的风格上。事实上这些年来他解决了很多很BT的技术问题，写出的代码搞定了很多我看来完全发疯的需求。就这一点，我是非常佩服他的学习精神、钻研精神以及娱乐大众的牺牲精神。为此我就不告诉你们他的ID叫“想你的我”，因为太难念，我们一致称他为水煮鱼。另外我要说的是，如果你没有水煮鱼那种被人切成一片片还要丢进锅里水煮再浇上辣椒也不怕的精神，还是起一个正常点的，好念的ID吧……事实上用自己真名的新人往往会得到比较亲切的帮助，不信你试试？
不要没事儿就在公共地盘报怨没有人帮助你。要知道在自由软件社区帮助你的人，九成九都是义务劳动，他们还要牺牲自己的工作和休息时间。没人欠你的。有个家伙因为五分钟没有人在QQ群里回答他的白痴问题，就开始大骂，于是他被我用各种方式羞辱了几个星期。没人会同情他。好吧，我不是一个心胸开阔的人。就是我这样一个小心眼又虚荣的家伙曾经在没有任何报酬的情况下翻烂了一本牛津高阶词典来翻译Python tutorial。这件事是我在失业的时候蜷缩在冬天冰冷的小屋里完成的，而且五年来我还把这件傻事重复做了四遍，正准备做第五遍。如果你能做到同样的程度，你也一样有资格去BT那些乱喊乱叫的家伙。如果你觉得应该支持比我更有RP的前辈，那可以无视我，请你去花钱买一本陈儒的Python源码剖析，或者去吹捧一下ZQ、Limodou、黄冬这些为大家做了很大贡献的人（不知道他们是谁？你真的是Python中文社区的成员吗？那你一定是新警察……）。
尽量少问软件破解的问题。我是说在自由软件社区。我不想争论道德高度的问题，这样的问题已经讨论过太多次了。我只想说，在自由软件社区找人要破解版或注册机，真的看起来很蠢。
语气请低调一些。趾高气扬的菜鸟只会被加倍的BT。这一点不需要多解释了，提醒一句：这个世界比你想像的NB的多。
遇到一个厚道的解答者，请珍惜，不要把他当作垃圾桶，什么白痴问题都丢过去问。学着自己解决问题永远是一种美德。如果你是一位青春美少女，对方是一个单身的宅男coder，另当别论，看在他厚道的为新人解答问题，任劳任怨的份上，嫁给他吧。
尽量帮助和你一样的菜鸟，不要BT他。这会使高阶的人力资源得到更有效的利用。就好像不要总是在游戏公会里请求顶级玩家帮你做新人任务一样，其实找个高你5级的帮手就很豪华了。同样你也应该多帮一帮比你更低级的玩家。
被BT时，请先检讨自己是否使用了挑衅技能。对于一个小圈子，往往BT新人会是老鸟们的重要福利之一。乱凑热闹或者灌水过多，都有可能招致灭顶之灾。在QQ群里发连锁消息尤其愚蠢。如果被BT，请先不要回击，通常来说，正是你这个新来的家伙破坏了生态平衡。如果觉得留下来学习更重要，就闭上嘴巴，多听少说。

1.3. IT行业人员的提问建议

里面提到的两个例子比较典型。另外后面有人评论中也给了一个例子。

1.3.1. 实例郁问

这几天对几个网友的请教方式颇感无奈。这里举2个实例：

有个网友因为项目比较急，而且之前也没有怎么接触过该项目的一些相关知识。正好我对这方面熟悉，于是找到我给出一些建议和提示。我大概知道了其要点，然后从头到尾给出了一些架构和技术上的要点。我觉得凭这些应该没有什么大问题了。没想到在未来几天里，该网友一直问我一些我已经解答过的问题。更意外的是同一问题问了至少5遍。我很郁闷，就问了一句，你工作几年了，他告诉我4-5年。我不再说什么了。如果工作4-5年，按照我的理解是不应该有这样的情况的。
另外一个网友因为一个小问题卡住了。我说了一下我的想法。他说他以前也做过，没有问题，而且特别坚持自己的意见。最后我只能说可以试一试我的建议。一个礼拜之后，他看见我，问我同样的问题，我惊诧道，"你还没有解决吗？"。他说还没有。我继续把我的建议重复了一遍。他过了一会高兴的回答我说可以了。

在上面的2个实例中，我感概太多了。

针对第一件事情，我觉得至少存在以下方面的问题：

1. 做事情太着急了
   2. 应该有把握整个project的能力
   3. 应该能够控制自己的心态
   4. 问问题之前最好总结一下，或者是思考一下人家给你的提示。不要一二再再二三的去问同一个问题大于3次。

对于工作4-5年的人，已经培养了自己解决问题，分析问题的方法。而且在把握一个项目上应该有一定的经验。冷静思考，沉着应对，都是现在浮躁的环境必须要有的。这些技能和心态和技术没有直接的关系。对中国的IT业，我一直认为是比较浮躁的。在这样的环境下，难道不能有自己的做事风格来行走着浮躁之面上吗？
针对第二件事情，我觉得可以这么理解：

1. 每个做IT人骨子里或多或少都自以为是，包括我自己也是。请教别人时还是那样
   2. 既然自己没有解决，何不试一试别人的建议呢，也许会给你带来意想不到收获。
   3. 多听听人家的意见或建议，对自己是有帮助的。放下一些不必要的面子。

如果坚持自己是对的，又不肯听从人家意见，那你问人家干嘛呢？
对待学习，对待工作，我们确实应该保持自信，但这绝不是自以为是。虚心请教他人，听取别人意见，在整个过程中我们会学到不少东西。别总以为自己是对的，每个人的知识面和知识的掌握程度都是有限的，这样自己的理解出现偏差和错误在所难免。
从另外一个角度上讲，我们在处理学习和工作上，应该知道一件事情如何去做，如何以什么样的心态去做。对于一个工作4-5年的人出现上面的情况我觉得实在不应该。这样的情况在刚工作时存在。随着自己的阅历增长，在态度，方式上都会逐渐成熟，都会有自己的一套方法。这些方法在面对一些复杂事情，未熟悉事情都是有帮助的。

1.3.2. Service Is Living 建议

所以我的想法是：

1. 戒浮戒躁，踏踏实实做事情
   2. 谦虚，自信，不是自以为是
   3. 有自己的做事风格，包括工作方式和心态。
   4. 沉着，冷静，从大局考虑。
   5. 做事情（例如向别人请教）前自己先做好必要的准备，想想。
   6. 态度
   7. 沟通。

2.1 回答的智慧

不要回答你不知道答案的问题

很明显，要是自己不知道，我们是不会回答的。但要注意我们的知识很容易变得过时，甚至从来没有正确过。比如数据库显式游标的性能并不比隐式的更好，但人们还是建议使用显式游标。如果你贴了什么与事实不符的回答在网上，肯定会有其他人能坏笑着指出你的错误。正确的靠后的回答要比错误的“沙发”更有用。
自行研究寻找你以前不确定或不了解的答案完全可以接受。在论坛上回答问题的好处之一就是我们能发现以前不知道的东西。那些让我们不知所措的问题也许能让我们了解更多有趣（有时甚至有用）的知识。

解释你的回答

Eric Raymond 建议新手把向高手求助作为自己学习过程的一种补充。在邮件列表上提问应该作为新手最后不得已的解决手段。在新手们吸收了集体的智慧，提供了对问题的详细描述，包括完整的环境参数和配置描述，加上他们尝试所有想得到的方法和读过所有相关手册、白皮书等等之后，才来向我们高手寻求最基本的帮助。当然那些只求不劳而获的废柴从不这样做，但我们还是应该有理有节地回应。
简单地给出正确答案是不够的，要试着解释为什么这个答案是正确的。这样提问的人才明白答案为什么正确，下周它就不会再贴一个几乎一样的问题。有可能的话，加上手册相关章节的链接。链接到特定的章节开头比链接到目录要好，但手册并不总是清晰地被划分成小段的。类似地，如果你需要更多的信息来回答问题，要解释你还需要知道什么以及为何需要。如果你需要（比如说）一个数据库的 explain plan 但怀疑提问人不知道这个概念，就给它手册的相关链接。

授人以渔，只提供最低限度的帮助

最有效的学习方法是自己去发现。教人如何检查自己的代码（使用 SQL> SHOW ERROR，查找错误，在文档中查看语法说明）比为它们重写代码要好。特别是在重写代码的过程中我们可能会违背我们不知道的一些行业规则。

展示你的操作过程

当回答与 SQL 有关的问题的时候最好添上一个实际运行的例子。从 SQL*Plus 里复制粘贴文本来展示你的论断的依据。当你自己研究找到答案时尤其应该如此。
如果由于时间和运行环境的限制（比如你无法实际操作一个数据库），可以贴出未测试的代码，但前提是：

你说明你的困难；
你认为没有测试过的代码示例也比完全没有代码强；
你认为它很可能是对的 :p

一段不能编译的代码是暴露不懂装懂的人最快的证据，所以你一定要确保有把握。

有分寸地使用幽默

论坛的许多用户第一语言不是英语。人们并不总能理解其它文化的幽默。有些提问者在有关工作的场合不期望有人说笑话。此外，即使在说同样语言的用户中，正确地表达幽默也需要借助于身势和表情信号。特别反讽是很难表达的。当然，幽默是能活跃讨论气氛的好东西，所以尽可能做一个聪明的幽默家（但是不聪明的笑话实在是糟透了）。表情符号可以用来表明你前一句话是有意的幽默，即使它算不上高水平的写作。简·奥斯汀反正不上 Oracle 的邮件列表 :)噢，但是冷嘲热讽可不行。

要是你说不了好话，就不要说:"你的母亲也这么告诉过你。"

没有愚蠢的问题，只有愚蠢的回答。如果你觉得别人贴出的某个问题不值得回答，那就不用回答。
记住：你是自愿的，没有人强迫你，你选择回答这个问题。所以，如果有人提了一个蠢问题浪费你的时间，你给它一个愚蠢（或愤怒或嘲讽或蔑视）的回答就是浪费你自己的时间。想法解释这样的问题不好在哪里，提示怎样更好地表述问题或者要求更多的细节。如果有新手提问“我的代码不起作用”，让它们描述运行时的行为，解释与预想的行为有什么不同，把错误信息和变量数据贴出来（如果有的话）。
如果有人特别不讲道理——在星期六早晨贴出一个“急！！！”的问题然后不断顶贴抱怨没人回复，尽管向它们解释你是个自愿者，论坛是免费服务，也没有产品支持协定。事实上，如果它们真的需要在有限的时间内得到答案，它们就应该大方一点买一个产品支持服务。同时，如果我怀疑发帖人是希望让我做它们作业的学生，我会要求分享它们的学分。

避免使用术语、难懂的缩写和俚语

Fnord。这只是又一种显示你相对提问者的优越感的方式。当然，你如果觉得看你帖子的人能懂，你也可以像使用幽默一样使用术语。或者，加一个术语词典的链接，虽然这么做就失去使用缩写的意义了。LOL。

永远永远不要用“RTFM”回复

叫新手“RTFM”完全是自大的表现。这种回复只满足了回复者的自我而不能让提问者有所收获，除了知难而退不再到论坛提问以外。Barbara Boehmer 告诉了我这一点。要记住 Oracle 的 fking manual 篇幅浩大，分为数十卷，而在线版的搜索引擎又不是那么好用。最起码，在写“RTFM”的同时给出到该死的手册的相关部分的链接。这样至少提问者下次就知道该到哪里找答案了。
STFW 至少是一样糟，甚至更糟的回答。搜索关于 Oracle 的问题需要许多技巧，不仅要会选择关键词，还要知道哪些结果可以相信。

为将来考虑

今后其它人能通过搜索结果读到你的帖子。当然如果它们用 Oracle Technology Network 的搜索引擎，它们可能是在找完全不同的东西而不会看你的帖子，但 Google 也索引 OTN 论坛。所以

注意让你的回答适用范围广一些

此外，像 Jakob Nielsen 提到的，你将来的老板可能也会看。

保持一颗新手的心

我们都曾经是新手。我们对于数据库的某些方面仍然都是新手。一个人的大脑根本不可能知道一切。即使 Tom Kyte 也时不时要向 Sean Dillon，Cameron O'Rourke 等人提问。所以下次你将要给一个“蠢”问题写一篇讽刺的回复的时候要记住：有一天，在某个论坛，你会提一个蠢问题，而一个自大傲慢的家伙会把你拍得无地自容。