【细品架构3/100】架构之问题识别

本文主要是继续研读了资深架构师王概凯Kevin执笔的《架构漫谈》系列的《架构漫谈（三）：如何作好架构之识别问题》的心得感觉。王概凯Kevin结合本身多年的架构经验，经过不一样的视角，从新审视架构的本质，从而产生一力做《架构漫谈》系列，做者但愿可以抛出本身从实践中得出的一些观点，并引起你们的一些思考，欢迎你们沟通讨论。

如须要阅读原文，请关注公众号“聊聊架构”，从历史文章中获取《架构漫谈》系列。

本文内容结构图：

 

 

1.  

按照以前的架构定义，架构就是要不断解决人遇到的问题，然而作好架构首先须要作的就是识别出须要解决的真实问题。通常来讲，若是把真正的问题可以找到，那么问题就已经解决了80%。这个能力基本上就决定了架构师的水平。

1.  

一则笑话：

女主人公：老公，把袋子里的土豆切一半下锅。结果老公是把袋子里的每一个土豆都削了一半，而后下锅。

固然不少人会说，这个是沟通问题，而后一笑了之。其实，出现这个现象是因为咱们大部分时候过于关注解决问题，急于完成本身的工做，而不关心“真正的问题是什么”而形成的。当咱们去解决一个问题的时候，必定要先把问题搞清楚。

去看看软件开发工做者的时间分配也能够看出，你们大部分时间花在讨论解决方案和实现的细节上，基本都不会花时间去想“问题是什么”。或者即便想了一点点，也是一闪而过，凭本身的直觉下判断。只有真正投入思考问题是什么的工程师，才可能会真正的成长为架构师。

以这个笑话为例，看看在咱们处理问题的时候，都会犯什么样的惯性错误：

被告知要处理一个问题，可是交过来的其实是一个解决方案，不是问题自己。

被告知要处理一个问题，直接经过直觉就有了一个解决方案，立刻考虑解决方案如何落地，或者有几种解决方案，选哪一个合适。

1.  

如何识别问题主体呢?

全部的概念基本都有一个很大的问题，就是缺少主语。而咱们你们都心领神会的忽略这个主语，沟通的时候也都觉得你们都懂得对方说的主语是谁，结果你们都一块儿犯错误。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着肯定了，再去讨论问题才有意义。

以上面切土豆的例子来分析：

1. 女主人提出一个问题，要切土豆下锅煮。

2. 男主人有一个问题，女主人交代了本身必需要完成的一个任务。

每一个人都是优先处理本身的问题，天然就选择了2，完成了这个任务。这也是大部分软件工程师处理的方式，以本身认为对的方式完成本身的问题，没什么不对啊，也难怪能获得咱们的共鸣。这个里面犯的错误是什么呢?

首先，女主人公提出的其实是解决方案，而不是烧土豆这个问题自己。女主人当时执行这个解决方案可能有困难，就把执行解决方案做为一个任务，委托给了男主人。

其次，男主人获得了一个任务，尽心尽职地把这个任务完成了。

最后的结果是什么呢，每一个人都作了不少工做，每一个人都认为本身作的是对的，所以没有一我的对结果满意。由于真正的问题没有被发现，天然也就没有被解决，那么后续还得收拾残局，还要继续解决问题。事实上本身的工做并无完成，反而更多了。把缘由归结为沟通问题也是能够的，但对于解决问题彷佛并无太多的帮助。由于要改进沟通，这也是一个大问题。搞明白目标问题“是谁的问题，是什么问题”，固然也是须要沟通的。为了帮助本身更快的搞明白，首先要作的事是问正确的问题。架构师应该问的第一个正确的问题就是：目标问题是谁的问题。

因此得出：

当咱们处理问题的时候，若是发现本身正在致力于把本身的工做完成，要立刻警戒起来，由于这样下去会演变成没有ownership的工做态度。在面对概念的时候，也会不求甚解，最终会致使没有真正的理解概念。

做为软件工程师或者架构师，咱们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。在上面故事里面，男主人要解决的，其实是这个家庭晚餐须要吃土豆的问题，目标问题的主体其实是这个家庭的成员。

1.  

如何识别问题边界呢?

明白了问题的主体，这个主体就天然会带来不少边界约束，好比土豆是要吃的，要给人吃的，并且仍是要给本身的家人吃的。“切土豆下锅”这个问题，由于识别了问题的主体，天然而然的就附带了这么多的信息。

后续如何煮，是否放高压锅煮，放多少水，煮多长时间等等，就天然而然可以问出来其余问题来了，说不定还可以识别出来，女主人给的这个解决方案多是有问题的。这个时候才算是真正的明白了问题。能够想象，这样下去最后的结果必定是你们都满意的，由于真正的问题解决了。只有真正明白了是谁的问题，才可以真正地完成本身的任务，真正地把本身的问题解决掉，而不是反过来。

由上面的分析能够看出，找出问题的主体，是作架构的首要问题。这也是我一再强调的，咱们要解决的问题，必定都是人的问题。进一步，架构师要解决的，基本都是别人的问题，不是本身的问题。

再进一步，咱们必定要明白，任何找上架构师的问题，绝对都不是真正的问题。为何呢? 由于若是是真正的问题的话，提问题过来的人确定都可以本身解决了，不须要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加剧要。

当问题的主体离架构师越远，就会让找出问题主体的过程越加困难，咱们再举一个软件行业比较熟悉的例子：用户给产品经理提出要求，想要一把锤子。这是典型的拿解决方案做为问题的。真正的问题的主体是谁，是用户仍是设计师仍是施工队? 若是产品经理当成是本身的问题，那么毫无疑问就给了锤子了。

咱们须要识别：用户到底是二传手，仍是问题的真正主体。若是是设计师，那么问题的边界就变成了设计师的问题，若是是施工队，那么问题就变成了施工队的问题，若是是用户，那么就要看看用户到底有什么困难，绝对不是要一个锤子这么简单。这也说明了，问题的主体对问题的边界肯定有多么的重要。

当明白了问题的主体，咱们才可能真正的认识问题是什么。由于问题的主体是问题的隐含边界，边界不肯定下来，问题就是不肯定的。一旦肯定了主体，剩下的就是去搞明白主体有哪些问题。

通常来讲，从问题暴露的点，一点点去溯源查找，必定会找出来谁的问题，以及是什么问题。最坏状况就是当咱们时间或者能力有限，实在是没法定位出是谁的问题的时候，好比系统出故障，也就意味着咱们没法根本解决问题。这时最好的办法就是去下降问题发生所带来的成本，尽可能去隔离问题影响的范围。给我留出时间和空间去识别真正的问题。

1.  

总结一下，要正确的认识问题，须要问两个问题：

1. 这是谁的问题？

2. 有什么问题？

当获得的回答是支支吾吾的时候，咱们就知道正确的方向在哪儿，以及须要作哪些事了。问题1会花比较多的时间，也是支支吾吾最多的地方，由于架构要解决的问题都是人的问题。可是一旦肯定了答案，问题2就会变得很是容易。能够这样说，架构师的能力大部分会体如今问题1的识别上。

在实际工做中存在不少的状况，都只是在完成本身的问题或任务，而忽略了问题或任务的根本：谁的问题、什么问题。做为架构师，不只是架构师，在面对问题时，而要更多的找出问题是什么，问题的主体是什么，从而只有有了主体，才可以肯定问题的边界，最终才会肯定出真正的问题所在。

做者：猿码道 连接：https://juejin.im/post/5b36e55d51882574dc41e948 来源：掘金 著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。