work

工作也有一段时间了，写点感悟和总结。

1. 问题

刚开始工作的时候还是一个诚惶诚恐，担心写不出来功能的心态，当陆陆续续的写出来了几个需求之后这种状态很快就消失了。随后心态转变为变为逢山开路，遇水搭桥。

想清楚问题很重要，每次拿到新的需求，或者遇到bug，都在不断的问自己当前所面临的问题是什么？通常情况下只要把问题想清楚，事情就迎刃而解。但还是存在少数情况下想不清楚的问题，想不清楚要思考卡在哪里，逐步排查，然后解决。最后无法依旧无法解决那就只能求助或者绕过去。

2. 沟通

之前只是听别人说交流很重要，但是没有深刻的体会，工作后感觉到交流确实非常重要。一般来说在拿到需求的时候要保证双方理解一致，当对方讲完需求的时候可以按照自己的理复述一遍，让对方确认是否有偏差，如果有就纠正。向对面描述概念，问题的时候要结合具体的例子，直接描述定义往往比较抽象，而类比的话寻找一个完美契合的例子还是很难的，只能用来描述某个点。可以多举出几个例子来解决，在 OOP 中叫做实例化。如果觉得对方说的不对，或者理解有偏差可以想出几个例子来反驳。在描述清楚需求时最好结合一个例子从头到尾将整个流程走一遍。这两点通常能够解决大部分的需求理解了，最终都是确保对方理解自己的意思，自己能够理解对方的意思。

3. 提问

• 该不该问

简单来说能用搜索引擎解决的问题最好不要问题。如果是项目中特有的知识，背景，那么要尽快的去问。只要能判断出来当前问题是无法被搜索到的那就张嘴问吧，自己摸索太费时间，但是这个是不太好判断的，搜索的时候不要在 CSDN 里面 递归。最后，熟读《提问的智慧》。

刚开始工作的时候有一个解协议入库的问题，因为是一个集群，两台机器之间存在一些限制。但是这个信息不知道，也没有文档，数据无法入库。排查了两个小时，最终寻求同事帮忙，对方五分钟搞定，这让我开始觉得要多问，请教，不要闷头走进死胡同。

• 怎么问

问问题的时候直接上来讲重点，一两句话说出问题，对方无法给出建议时再去补充上下文，前因后果等信息。因为大家时间都很紧张，讲完前因后果太浪费时间了。