作为工程师, 对问题的描述务必清晰, 准确, 完整, 尽量避免"连不上", "报错了", "跑不起来", "挂了"等模糊且无意义的表述. 这是作为工程师一个基本的素质. 对问题的描述应该提供尽量多的信息, 例如:
- 服务跑不起来, 报了个 xxx 错
- xx 服务连不上了, 报了个 xxx 错
- 我在进行 xx 操作的时候报错了, 错误码是 xxx, 报错信息是 xxx
如果是远程(微信,QQ,邮件)协作团队, 在描述问题的时候, 还应该主动附上完整的报错日志, 请求\响应报文, 相关软件版本等必要的信息. 还有, 作为工程师你应该知道在哪儿能看到报错信息, 很多工程师甚至不知道浏览器有"开发者工具", 不知道大多数软件都有日志文件. 很多工程师还会习惯性的忽略英文报错, 我知道, 大家英文都不好, 有时候确实看不懂, 但是起码你不能当那些报错不存在.
有篇经典的文章, 我不得不再次引用: 提问的智慧. 很多时候, 把话说清楚能让你省很多麻烦, 省很多工作量. 下面我们举个例子, 比如: xx 服务连不上
- 错误表述: xx 服务连不上了!为啥?
- 正确表述: xx 服务连不上了, 报超时(time out), 或报主机(网络)不可达, 最好附上报错截图.
服务连不上的情况有很多种情况:
-
超时(time out)
确认目标服务是否正常, 如果是 web 服务, 可以使用浏览器, 或者 curl 命令, 或者 postman 等工具发送 http 请求; 如果是数据库, 可以使用相应的连接工具测试.
-
网络不可达
通常是网络路由异常, 应该检查电脑与目标机器是否处在同一网络环境中, 检查自己使用的是 wifi 还是有线网络, 理论上是否能连接到目标机器. 可以通过 ping 检查.
-
主机不可达
网络正常, 但无法连接到目标主机, 极有可能是配置错误. 可以通过 ping 检查. 同时跟服务提供方确认服务地址.
通过检测, 如果服务可用, 则检查代码中的配置. 如果服务不可用, 则联系服务的负责人寻求支持, 同时最好附上报错的截图.
不管你遇到什么问题, 如果你想解决, 就要提供线索, 否则很可能会收到以下回复:
RTFM
RTFM 是 Read The Fucking Manual 的缩写，译为中文大概可以是“去读那操蛋的手册”。一句话糙理不糙的话，直如当头棒喝，稍有觉悟的人听了这句话以后就能够脱胎换骨，成就一生。这句话的出处大概是在：http://www.readthefuckingmanual.com/ , 一个在首页论述你应当去读手册的网站。摘抄一段：If you follow this advice, probability is that up to 8 times out of 10, you can solve your own problem right there and then, without any hassle and frustration, and without having to call the manufacturer.
GIYF
读手册是治根治本的方法，但不那么容易见效，而且许多知识没有人整理成手册。所以很多时候遇到急事，就不那么容易通过 RTFM 来解决了，这时我们要记得 GIYF。GIYF 就是 Google Is Your Friend，当遇到少见的代码编译错误号，连接数据库抛出异常，遇到一个没见过的英文缩写，或者在 A 机运行正常的代码在 B 机总是跑不起来，就是到了去探访 Google 这个朋友的时候了！
STFW 和 JFGI
这两个词，大概可以看作 GIYF 的升级版，语气更加严厉一些。它们的全拼分别是 Search The Fucking Web 和 Just Fucking Google It。Just Fucking Google It 也有一个专门的网站── http://justfuckinggoogleit.com/，里面的一句话道破天机：Someone thinks you are an idiot because you were too stupid to check Google before asking a question。无论你信与不信，去 Google 搜索能够解决你遇到的 80% 以上的问题，《Google 搜索引擎入门到精通》是程序员的必读书目。
其实这几个缩写的核心思想都是一致的：就是自己的问题自己想办法解决。不要把论坛、maillist、同学同事、亲戚朋友或客服电话看作解决问题的第一选择。要有 the buck stops here （什么意思？JFGI！）的责任心和勇气，摆脱对其他人的依赖，才能真正提高自己。
http://www.kuqin.com/english/20120207/317868.html
当然, 工程师通常也不是单打独斗, 通常是有团队的, 团队内部是有分工的, 也不能一个人什么都干, 要搞清楚自己的边界. 对于开发工程师而言, 与软件开发不直接相关的问题, 大可以抛给同事. 但是前面说了那么多, 你大概知道自己应该如何跟同事描述问题了吧, 千万别只说"xxx 不能用了"就了事.