您的位置:知识库 » 软件设计

架构漫谈(三):如何做好架构之识别问题

作者: 王概凯  来源: InfoQ  发布时间: 2016-04-17 10:47  阅读: 23485 次  推荐: 22   原文链接   [收藏]  

  上篇:架构漫谈(二):认识概念是理解架构的基础

  按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。

  那么面对问题有哪些困难呢?

  我们先看一则笑话。女主人公:老公,把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半,然后下锅。

  当然很多人会说,这个是沟通问题,然后一笑了之。其实,出现这个现象是由于我们大部分时候过于关注解决问题,急于完成自己的工作,而不关心“真正的问题是什么”而造成的。当我们去解决一个问题的时候,一定要先把问题搞清楚。这也是我为什么要单独写一篇文章讲这个的原因。去看看软件开发工作者的时间分配也可以看出,大家大部分时间花在讨论解决方案和实现的细节上,基本都不会花时间去想“问题是什么”。或者即使想了一点点,也是一闪而过,凭自己的直觉下判断。只有真正投入思考问题是什么的工程师,才可能会真正的成长为架构师

  以这个笑话为例,看看在我们处理问题的时候,都会犯什么样的错误:

  1. 被告知要处理一个问题,但是交过来的实际上是一个解决方案,不是问题本身。
  2. 被告知要处理一个问题,直接通过直觉就有了一个解决方案,马上考虑解决方案如何落地,或者有几种解决方案,选哪个合适。

  那么如何识别问题呢?

  所有的概念基本都有一个很大的问题,就是缺乏主语。而我们大家都心照不宣的忽略这个主语,沟通的时候也都以为大家都懂得对方说的主语是谁,结果大家都一起犯错误。识别问题的一个最大的前提就是要搞清楚:是谁的问题。这个搞清楚了,问题的边界也就跟着确定了,再去讨论问题才有意义。

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

  1. 女主人提出一个问题,要切土豆下锅煮。
  2. 男主人有一个问题,女主人交代了自己必须要完成的一个任务。

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

  1. 女主人公提出的实际上是解决方案,而不是烧土豆这个问题本身。女主人当时执行这个解决方案可能有困难,就把执行解决方案作为一个任务,委托给了男主人。

  2. 男主人得到了一个任务,尽心尽职地把这个任务完成了。

  最后的结果是什么呢,每个人都做了很多工作,每个人都认为自己做的是对的,因此没有一个人对结果满意。因为真正的问题没有被发现,自然也就没有被解决,那么后续还得收拾残局,还要继续解决问题。事实上自己的工作并没有完成,反而更多了。把原因归结为沟通问题也是可以的,但对于解决问题似乎并没有太多的帮助。因为要改进沟通,这也是一个大问题。搞明白目标问题“是谁的问题,是什么问题”,当然也是需要沟通的。为了帮助自己更快的搞明白,首先要做的事是问正确的问题。架构师应该问的第一个正确的问题就是:目标问题是谁的问题。

  当我们处理问题的时候,如果发现自己正在致力于把自己的工作完成,要马上警惕起来,因为这样下去会演变成没有ownership的工作态度。在面对概念的时候,也会不求甚解,最终会导致没有真正的理解概念。

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

  明白了问题的主体,这个主体就自然会带来很多边界约束,比如土豆是要吃的,要给人吃的,而且还是要给自己的家人吃的。“切土豆下锅”这个问题,因为识别了问题的主体,自然而然的就附带了这么多的信息。后续如何煮,是否放高压锅煮,放多少水,煮多长时间等等,就自然而然能够问出来其他问题来了,说不定还能够识别出来,女主人给的这个解决方案可能是有问题的。这个时候才算是真正的明白了问题。可以想象,这样下去最后的结果一定是大家都满意的,因为真正的问题解决了。只有真正明白了是谁的问题,才能够真正地完成自己的任务,真正地把自己的问题解决掉,而不是反过来。

  由上面的分析可以看出,找出问题的主体,是做架构的首要问题。这也是我一再强调的,我们要解决的问题,一定都是人的问题。更进一步,架构师要解决的,基本都是别人的问题,不是自己的问题。再进一步,我们一定要明白,任何找上架构师的问题,绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话,提问题过来的人肯定都能够自己解决了,不需要找架构师。架构师都要有这个自觉:发现问题永远都比解决问题来的更加重要。

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

  我们需要识别:用户究竟是二传手,还是问题的真正主体。如果是设计师,那么问题的边界就变成了设计师的问题;如果是施工队,那么问题就变成了施工队的问题;如果是用户,那么就要看看用户到底有什么困难,绝对不是要一个锤子这么简单。这也说明了,问题的主体对问题的边界确定有多么的重要。

  当明白了问题的主体,我们才可能真正的认识问题是什么。因为问题的主体是问题的隐含边界,边界不确定下来,问题就是不确定的。一旦确定了主体,剩下的就是去搞明白主体有哪些问题。这个就比较直接了,常用的方式就是直接面对主体进行访谈,深入到主体的工作生活当中,体验并感受这些问题,甚至通过数据的反馈来定位问题。这个大家就比较熟悉了,我就不展开了。

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

  总结一下,要正确的认识问题,需要问两个问题:

  1. 这是谁的问题?
  2. 有什么问题?

  当得到的回答是支支吾吾的时候,我们就知道正确的方向在哪儿,以及需要做哪些事了。以我的经验,问题1会花比较多的时间,也是支支吾吾最多的地方,因为架构要解决的问题都是人的问题。但是一旦确定了答案,问题2就会变得非常容易。可以这样说,架构师的能力大部分会体现在问题1的识别上。

  下篇:架构漫谈(四):如何做好架构之架构切分

22
1
 
标签:架构

软件设计热门文章

    软件设计最新文章

      最新新闻

        热门新闻