最近在弄一个新项目,各种麻烦,不过现在回头一想,关键的几个问题却是由不怎么了解实施detail的人提出来的,而非我们实现者自己。
有时候我们太专业了,专业意味着拥有专业自信,但我们再专业,有些问题也超出了我们的能力范围,我们也只能是站在一个相对的detail level来看问题,总不能深入到所有的detail吧,那就要去搞明白所有的依赖库的source code了。
但是有了专业自信,我们就会获得一个这样的倾向,在一个相对的detail level来模糊的估计一下那些我们不了解的更detail的level,比如说我根据我的认识判断这东西可能80%,90%能干,然后我就会下一个结论这东西能干。但是你要问我具体这东西怎么干,怎么一步步把它干出来,那我目前是不知道这个步骤的,只能说凭着我专业的判断我是这么认为能干的,接下来还得去查相关的文档再做调研。
但想象若是一个没有专业自信的人,或者说对专业完全不怎么了解的人,他来看这个问题的话,就没有我们专业自信的谜之模糊倾向,他肯定是希望100%的了解到具体是怎么一步步做的,这样他才会有他对这个项目的自信。
然而,最重要的问题,最可能的坑,往往在专业的人模糊忽略掉的那20%,10%里。所以,当我们回答问题的时候,我们是不是应该回答不知道而不是用专业自信去模糊判断呢。
最近看了《恰如其分的软件设计》,翻译的是真的烂,完全是看不懂。或者说其实这书里全是理论也没讲什么。不过它的核心是架构要围绕着风险来设计,以消除风险为目标。
风险,原来是风险,真的是非常简单的概念。但是我们以前谈的架构都是围绕着功能。但是看一个项目难道不是最先看这个项目的风险吗,这是一种直觉,非常简单的直觉,然而我们专业的都把它忽略掉了。
所以我说反而是不怎么了解实施detail的人提出来了关键问题,比如授权怎么做,域名有没有风险,这些都被我们专业的开发者模糊的忽略掉了。但是这些都是,都是风险,都是直接从风险出发提出来的问题,甚至可以说就是一个一般的直觉。
然而我们专业开发都miss了,我们太专业了。所以我的一大领悟是,专业的思考完一件事以后,跳出专业,回过头来再以使用者思维,维护者思维,黑客的思维,等等各种受体的思维再重新审视一下这个专业的思考,看看是不是还有什么是专业思维的狭隘带来的模糊,以及没有想到的地方。