飞跃迷雾,把OO看清楚(二)

11-03-25 showerxp
         

(二)不值得做的事情,更不值得做好——再探需求

有的人说,软件建模过程有一套科学的方法论,有自己的规律,是软件长期发展演进总结出来的。对此,我是赞同的。也有人对上面电梯例子列举了一些更加优化改进的业务流程,比如更科学的算法以至于让等待电梯的人获得更加公平的机会。对此,我也认为这可能是电梯未来的发展方向。但是,以上两者看似无关联的意见以及我们讨论的电梯例子都忽视了一个重要的因素——需求,更进一步说是客户欲望。

这里可能有个问题,难道电梯运行流程不是需求吗?如果将需求看成客户欲望,那么电梯流程就不是需求。我上面例举的电梯系统,其实没有引入一个软件系统的重要因素——客户。不同客户有着不同的需求,如果客户是电梯整套设备制造商,那么他的诉求可能是安全、稳定、长期运行、无人看守等等;如果客户是要开发一套如“电梯惊魂”之类的惊悚类游戏,而要模拟一个不太正常的电梯,那么客户的诉求可能是不确定、阴暗、复古、恐怖等等。这样,客户不同,我们就得出侧重点不同的电梯(也有可能连电梯都不是)。

光讨论方法论是不够的。比如,有人说,有一套杀死蟑螂万无一失的方法——将蟑螂固定在一块木板上,用另外一块木板敲打它。这样做,蟑螂肯定必死无疑,问题是没有人会花钱“引进”这套方法。因为这个方法把最难的部分——将蟑螂固定在木板上(可以把这个过程看成捕获需求)交给了客户。所以方法论可以解决我们“怎么做”的问题。但是,不能解决“做什么”的问题。先搞清出发的方向,再考虑怎么走。我同意软件建模是有一套科学的、有规律的方法,但是不同意有了这个共识就使得建模结果趋于一致。因为即便相同的客户和相同的方法论,建模者对需求不同的考量,也会产生不同的软件模型。

写到这里,我考虑回头再看看我的标题——飞跃迷雾,把OO看清楚。我看见过,有老前辈这样的言论:“软件工程看起来已经‘进化’成一门诡辩方法论的科学,它不去解决引起问题的根源,而是力图去安抚和使用花言巧语来哄骗参与其中的人们”。可能言过了,但是事实正在向这方面发展。现在很多人在软件工程领域就言必称“模式”、“框架”,还有层出不穷的方法论,仿佛越是晦涩难懂,越让人感觉有见解有深度。我并不是贬低那些模式、框架、方法论。有人将模式定义为一种表达一定的上下文、问题和解决方案之间某种特定关系的三部分规则。我则认为,这个“上下文”、“问题”、“解决方案”三要素也可以引申到框架、方法论中。而现在正是这许多抛开“上下文”只由“问题”和“解决方案”构造的软件工程领域,让人感觉浓雾重重,深陷其中不知所在。

在软件工程世界里,一名战士手拿OO(抽象化)这把利剑,毫无畏惧的向一头怪兽,一头总是在变化的怪兽——需求,刺去……

         

6
banq
2011-03-26 08:48

软件工程之所以是工程,而不是工匠,其实是个人和群体的区别,而要驱动群体协同工作,需要一套方法论或模式,否则只有靠权威和专制了。

方法论是解决“怎么做”,是解决如何把客户需求“分析细化”这个方向的“怎么做”问题,这样我们才能了解客户到底是想“做什么”。不能就“方法论”论方法论,这是片面的。

为什么楼主自己在阐述客户需求和方法论时,没有想到他们之间的联系呢?而是认为彼此没有联系的两个事物呢?

引用我在我新浪微博中一个案例:

昨湖卫相亲节目,研究生有洁癖,相亲丈母娘认为会影响事业,双方各执一词,这是典型中西思维两个极端,丈母娘代表中思维,注重事物之间的联系;研究生接受西教育是西方分析思维,容易割裂联系孤立看事物。

另外关于你的老前辈一句话:软件工程看起来已经‘进化’成一门诡辩方法论的科学,它不去解决引起问题的根源,而是力图去安抚和使用花言巧语来哄骗参与其中的人们

这句话本身就逻辑上矛盾,软件工程本身就是不是科学,而是工程技术,“软件科学”才是科学,专攻算法和数学,还是取名“软件算法或算术”好了,混淆视听,老前辈说这句话本身是因为其屁股坐在软件算法这个地盘。

所以,要引导大家搞他的纯学术研究,可惜,软件工程技术中都是日常与人打交道,还是学会一套正常人的思维语言方法比较好服务于人类,否则就是你再智慧是外星人,和我们语言不通,如何服务呢?如何协调呢?每次都要翻译吗?谁保证翻译不失真?数学家先把信息传播不失真这道题目求解了再来插足软件工程吧。

人类那点数学知识能够上天入地了,可惜就能飞往星际边缘,也就离人自身越来越远,少点科学迷信,多点理智,多点朴素象形思维,不好吗?你看老美人多可爱,人家可是两者娴熟结合,而我们总是在走极端 啊。

showerxp
2011-03-26 10:30

2011年03月26日 08:48 "

banq"的内容

软件工程看起来已经‘进化’成一门诡辩方法论的科学,它不去解决引起问题的根源,而是力图去安抚和使用花言巧语来哄骗参与其中的人们 ...

表明这一观点的人,本身就是老美资深需求分析方面专家,上面所说的“问题的根源”就是现实客观世界的需求问题。事实上,他的观点是——运用方法论之前要考虑客户愿望,要考虑方向性问题,如诺不然就会出现“不值得做得事情,也不值得去做好”的问题。

比如:用例是获得业务流程的半形式化方法。那么,严格的恪守该方法,实践这一方法就能获得清晰的业务流程吗?不见得。重要的不是在于用例这一方法,而是在于获得业务流程的过程。客观世界可能有100条业务流程,根据客户需求,软件系统只需专注了解其中5条。那么,用例来表示其中的5条,就是如虎添翼。而重点是如何确定只需要了解其中5条,这是需求分析师的工作重点,是通过问题分析、寻找切入点、降低含混性、促进需求推进等一系列过程获得的。而其中用到的的沟通谈话技巧,心里分析,语言运用等等并不是软件工程特有的,而是很早就产生的学科。

所以,本文强调的是——不值得做的事情,也不值得去做好。

axgle
2011-03-26 11:30

说的好.需求可以视为方法论的context之一.

可够选择的方法论,也可以视为实现需求的一个context,即策略集.

强调需求,还是强调需求的实现:)....两者其实都重要.

banq
2011-03-26 11:35

写得很很好,不值得做的事情不值得做好,也可谓是一个哲学观点,实践难度就在如何知道值得的尺度。

我随想探讨一下,成语有句:过犹不及,指事情过了还不如原来不及的程度,以很小的代价尝试也许是一种方法。客户的需求也许在不断尝试实现中不断明朗和确定的。

这个很小的代价看什么人判断标准,会模式框架的人用现成框架就迅速搭出架子尝试,而不懂模式框架的人则认为那费时,本身就是尝试不值得做好。

方向性问题研究实际是最重要的,我们宁可花费大量时间和精力在研究值得与否上,都不能拔腿立即出发。

这个现象和投资股票很类似,个股选择耗费时间精力,一旦确定个股方向确定,战术阶段就是等待。而软件需求不同是还需要讲究战术阶段的方法,否则影响判断依据。

不知我的想法方向是否已经纠正到楼主本帖强调的方向上?

2Go 1 2 下一页