{转载} 关于软件架构设计的思考 by 杨军(yangjunpro)

303 views
Skip to first unread message

pongba

unread,
Dec 5, 2008, 1:38:19 AM12/5/08
to TopLanguage
来源: http://hi.baidu.com/yjpro

杨军之前在 TopLanguage 上只发了三个主题,但字字珠玑:

[1] 有些事情做起来比想象中容易
[2] 有关读书方法的一点想法
[3] 一件事情如果你没有说清楚,十有八九不能做好

以下是 "关于软件架构设计的思考" 的正文
--------
最近在重构设计。这一回自己吸取了之前的教训,在想清楚整个设计的架构之前,一直没有动手写太多实

际的code,更多的时候是用伪码来描述验证自己的设计思想。

花了三天的时间,在一条设计道路上不断地思考,尝试,最终发现并不太可行,于是改换另一个思路

续进行设计,经过一天时间的设计,发现这个思路也存在一定的缺陷,及至今天,才算是基本确定下来整

体设计的框架。

如果自己这一次还是在设计阶段浅尝之后就开始实际动手coding,恐怕就未必能够及时地意识到设计中

存在的不足了。很多时候,虽然在实际编码的过程中我们能够体会到设计中存在一些缺陷,但是身陷于

细节实现其中,大脑往往被"
快点搞定它"的想法所充斥,已经无暇再回到比较高的角度来思考整

个架构的合理性了
,这种情况下,往往要待到编码到一个原有的设计缺陷已经无法忍受的状态下,才

会明确清晰地意识到有必要重新考虑设计层面的变化了。

但是到了这种时候,也往往意味着前面大量的实现工作要被推翻重来,不啻为一种浪费。

在设计阶段,作得细致一些,尽量不要让自己陷入实现的细节中纠缠,即使在仅凭思考和抽象已经不易

把握系统复杂度的时候,也不要轻易诉诸实现,而是借助于流程图,伪码这样的抽象层次较高的手段来协

助自己建立起对系统的具体理解,则有助于以一种有序的方式把握整体的设计了。


设计工作往往是抽象的,不易把握的,甚至是有些痛苦的,因为你往往要从一个空白的起点开始通过抽

象,组合,等等手段构建出一个假想的符合要求的目标架构,这种不够厚实,欠乏实物支撑的感觉经常会

让一个设计经验不是很丰富的开发人员在设计阶段萌生出逃避设计,尽早切入具体coding的想法。

而相比之下,实现工作则具体得多,也易把握得多,也更容易带来快速成就感,所以开发人员可能更容

易倾心于一个具体模块的实现。 这也是诱使我在前面的开发过程中在设计还未足够明晰的情况下就过早

介入具体实现的主要原因。

--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

Kenny Yuan

unread,
Dec 5, 2008, 2:49:29 AM12/5/08
to pon...@googlegroups.com
大部分同意文中观点。

补充一下哈:可能有人会争辩说:如果不写些代码进行实验或者启发,就完不成好的设计。其实这一条只能说明设计者经验的不足,或者方法上不善于总结:不知道自己过去是如何成功、如何失败的。

至于Agile,应该是另外一个model(依我的个人理解)

我一直认为,重新设计一个有过经验的东西(包括重构和重生)和做一个未知的新东西是有很大区别的。前者适用于文中的原则。

--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/


li li

unread,
Dec 5, 2008, 3:04:25 AM12/5/08
to pon...@googlegroups.com


2008/12/5 pongba <pon...@gmail.com>



细节实现其中,大脑往往被"
快点搞定它"的想法所充斥,已经无暇再回到比较高的角度来思考整

个架构的合理性了

赞!最近看《设计模式解析》,这就是作者提倡的"背景设计"原则。虽然用C语言写程序,但也非常受用!

Rui

unread,
Dec 5, 2008, 4:09:58 AM12/5/08
to TopLanguage
我谈谈我的一点浅见.
Fowler那本企业架构模式PEAA,对于架构师来说应该是反复阅读的一本.
读过后回头看为什么样Fowler把Layer模式放在最前面,一方面这是个比较容易理解的模式,另一方面,这也是非常重要的一种模式.
我手下有个刚刚提拔的系统分析员,做design和coding是个好手.但做architecture是新手.内天就某一中型项目焦头烂额找我来
了.
简化一下场景吧.它这是一个工厂的自动跟踪系统,简单讲就是产品在生产过程中通过光电和电子装置检测到产品的运动方向后进行一些统计和数据处理.
该SA的还算是中科院出来的正牌OO理论专家呢.搞了一个挺复杂的OO设计,但现在对于好多异常情况处理不了.
我打开了UC和Class diagram...我的妈呀.看到一蜘蛛网.
没有细看图,我就直接跟内SA说,你这设计100%有问题.内SA满脸不服气的样子,好象说你也没看class diagram呢,你怎么知道我这设计
有毛病呢....
当时就开玩笑说,你和我下盘棋,下到一半让吴清源来看,他即使不看过程,只看结果,也知道是俩臭棋篓子.....
该SA的问题是这个设计没有层次性....或者读过Fowler那本书Layer模式的,就知道....一个比较完善的OO设计,完成后是有清晰的层次
性,或者说,即使Class Diagram完全展开,那类与类之间也不应该是网状的,而应该是层次性,并且层次间的关联关系越少越好.

就我的经验,新手SA/Architecture最容易犯的错误,就是只见树木不见森林.Architecture要既有望远镜,又有显微镜,并且要知
道什么时候该用望远镜,什么时候该用显微镜.
我同意原贴中关于快速prototyping, pseudocode来做概念验证,但就我感觉来说,新的Architecture更容易犯的,是这种
只见树木不见森林的错.
举个例子来说,前面这个新手SA,他的一个显而易见的错误,是把各种异常情况都暴露到表面...
这个系统是一个机电一体化+软件的项目,对于底层的机电一体化系统来说,自然包括各种各样的异常因素,比如说两个产品同时通过时,导致光电眼检测定位天
线检测不同步.原来的设计,把这个异常类和业务类完全混到一起去了.
我当时就告诉该SA,对于最终客户(在这里就是业务类喽),他有什么样的必要知道这个错误呢???为什么你要把这个类混在一起呢..
其实这里的原因就是该SA在做设计时,宏观视野不足,而微观视野过多了.他满心以为自己考虑的很周到,却没有想到这样最终导致了糟糕的设计.

所以原贴说:
"在设计阶段,作得细致一些,尽量不要让自己陷入实现的细节中纠缠"..这个表述,看起来好象矛盾(既要细致,又不能陷入细节..),实际上我觉得是没
说到点子上.

很多架构设计是top down的,如果你遵循分层原则,并且理解层与层间依赖应该最少.你就会很容易的判断出哪些细节是我这一层应该考虑的,哪些细节
我不应该考虑(应该交给下一层去考虑).如果不记住这个原则,你一样最终还可能陷于混乱,即使你有prototyping和pseudocode也一
样.关键在于Architeture要善用两种不同的工具(望远镜和显微镜).


我的表达能力不是很好....观点欢迎拍砖.


On 12月5日, 下午2时38分, pongba <pon...@gmail.com> wrote:
> 来源:http://hi.baidu.com/yjpro
>
> 杨军 <http://hi.baidu.com/yjpro>之前在 TopLanguage 上只发了三个主题,但字字珠玑:
>
> [1] 有些事情做起来比想象中容易<https://groups.google.com/group/pongba/browse_frm/thread/9a459b6efe94...>
> 。
> [2] 有关读书方法的一点想法<https://groups.google.com/group/pongba/browse_frm/thread/20a08b6201d8...>
> 。
> [3] 一件事情如果你没有说清楚,十有八九不能做好<https://groups.google.com/group/pongba/browse_frm/thread/6f6140744ab9...>


> 。
>
> 以下是 "关于软件架构设计的思考" 的正文
> --------
> 最近在重构设计。这一回自己吸取了之前的教训,在想清楚整个设计的架构之前,一直没有动手写太多实
>
> 际的code,更多的时候是用伪码来描述验证自己的设计思想。
>

> 花了三天的时间,在一条设计道路上不断地思考,尝试,最终发现并不太可行,于是*改换另一个思路*继


>
> 续进行设计,经过一天时间的设计,发现这个思路也存在一定的缺陷,及至今天,才算是基本确定下来整
>
> 体设计的框架。
>
> 如果自己这一次还是在设计阶段浅尝之后就开始实际动手coding,恐怕就未必能够及时地意识到设计中
>

> 存在的不足了。很多时候,虽然在实际编码的过程中我们能够体会到设计中存在一些缺陷,*但是身陷于
>
> 细节实现其中,大脑往往被"**快点搞定它"的想法所充斥,已经无暇再回到比较高的角度来思考整
>
> 个架构的合理性了*,这种情况下,往往要待到编码到一个*原有的设计缺陷已经无法忍受*的状态下,才
>
> 会明确清晰地意识到有必要重新考虑设计层面的变化了。
>
> 但是到了这种时候,也往往意味着前面大量的实现工作要被推翻重来,不啻为一种浪费。
>
> 而*在设计阶段,作得细致一些,尽量不要让自己陷入实现的细节中纠缠,即使在仅凭思考和抽象已经不易
>
> 把握系统复杂度的时候,也不要轻易诉诸实现,而是借助于流程图,伪码这样的抽象层次较高的手段来协
>
> 助自己建立起对系统的具体理解,则有助于以一种有序的方式把握整体的设计了。*


>
> 设计工作往往是抽象的,不易把握的,甚至是有些痛苦的,因为你往往要从一个空白的起点开始通过抽
>
> 象,组合,等等手段构建出一个假想的符合要求的目标架构,这种不够厚实,欠乏实物支撑的感觉经常会
>
> 让一个设计经验不是很丰富的开发人员在设计阶段萌生出逃避设计,尽早切入具体coding的想法。
>

> 而相比之下,实现工作则具体得多,也易把握得多,也更容易带来*快速成就感*,所以开发人员可能更容

Kenny Yuan

unread,
Dec 5, 2008, 4:40:38 AM12/5/08
to pon...@googlegroups.com
说到生产线,呵呵,有一个笑话是关于化繁为简的(虽然不一定真实)
虽然是笑话,但对设计者也应该有些启示吧

博士和小工的区别

据说这是真实的笑话,搏君一笑,看看什么叫资源浪费

话说联合利华新换了一批自动香皂包装机以后,经常出现香皂盒子是空的没有香皂的情况,而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不,一个由自动化,机械,机电一体化等专业的博士组成的Solution队伍来解决这个问题,没多久他们在装配线的头上开发了全自动的X光透射检查线,透射检查所有的装配线尽头等待装箱的香皂盒,如果有空的就用机械臂取走。

不巧,中国一乡镇企业生产香皂也遇到类似问题,老板吩咐线上小工务必想出对策决之,小工拿了一个电风扇放在装配线的头上,对着最后的成品吹之,空盒子被吹走,问题解决之.

pongba

unread,
Dec 5, 2008, 4:56:20 AM12/5/08
to pon...@googlegroups.com


2008/12/5 Rui <cao...@gmail.com>
关键在于Architeture要善用两种不同的工具(望远镜和显微镜).

这句话对我印象最深刻,尽管它很抽象,但高层的指导原则几乎总是抽象的。

架构是个很难的领域,优秀的程序员一抓一把,优秀的架构师凤毛麟角。我也有打算好好学习实践一下这个领域:)

pongba

unread,
Dec 5, 2008, 4:53:29 AM12/5/08
to pon...@googlegroups.com


2008/12/5 Kenny Yuan <yuank...@gmail.com>

话说联合利华新换了一批自动香皂包装机以后,经常出现香皂盒子是空的没有香皂的情况,而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不,一个由自动化,机械,机电一体化等专业的博士组成的Solution队伍来解决这个问题,没多久他们在装配线的头上开发了全自动的X光透射检查线,透射检查所有的装配线尽头等待装箱的香皂盒,如果有空的就用机械臂取走。

不巧,中国一乡镇企业生产香皂也遇到类似问题,老板吩咐线上小工务必想出对策决之,小工拿了一个电风扇放在装配线的头上,对着最后的成品吹之,空盒子被吹走,问题解决之.

这个我也听过,印象很深刻,这次你贴出来之后我又想,从机器学习的角度来看,这个小工的 feature selection 做得非常棒,因为这本质上是一个分类问题,只要摸到那个对于区分最关键的 feature 就事半功倍了,而小工 select 出来的这个 "重量" 就是一个最佳 feature 。

Du Lei

unread,
Dec 5, 2008, 5:06:09 AM12/5/08
to pon...@googlegroups.com
越是学历高,考虑问题的时候越容易划地自限。所谓拿这个锤子看见谁都像个钉子。

2008/12/5 pongba <pon...@gmail.com>

arena

unread,
Dec 5, 2008, 5:09:06 AM12/5/08
to TopLanguage

很想从比较高的角度去思考整个系统的实现,但往往是抽象能力不够,对所涉及的方方面面知识还没融汇贯通,这样情形下,觉得还是coding实现一个简陋
的demo有助于思考

pongba

unread,
Dec 5, 2008, 5:11:03 AM12/5/08
to pon...@googlegroups.com


2008/12/5 pongba <pon...@gmail.com>
一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候,如果脑子里有一个与问题场景有某些相似性的既有方案,就会抑制不住地思维被该方案占满,很难实现fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法,为此也在阅读思维/认知科学方面的书,有一些heuristics能够有一定的作用,但是每每还是发现会思维落入盲点 :D

但另一方面,没有知识又真的很难思考。很多时候方案难以完全逆向导出,而是通过联想发现某个既有知识能够被用来解决手头问题的。

我想最终的方案肯定是critical的接受知识,critical的思考。具体的思维方法还在不断反思中..

樊帆

unread,
Dec 5, 2008, 5:26:19 AM12/5/08
to pon...@googlegroups.com
小工用电风扇解决的原因,我觉得是一个熟能生巧的问题。
工人日常所做的工作导致了他的思考模式必然是现实、低级的,但在检查空盒的方面却发挥了实效。
而专家因为工作原因,思考的思路必定是专业考究的,但却忽略了小技巧的现实效用。

因此我一直以来认为好的SA必定是Programmer出生,而且也必定是优秀的,so,要做好SA,先做好coding,当然这里的coding是广义的。毕竟望远镜和显微镜是有差异的,必定要身处其中才能有深刻体会的。

Yi Yang

unread,
Dec 5, 2008, 5:27:07 AM12/5/08
to pon...@googlegroups.com
刚想说重量是关键就被pongba抢先了,补充一下个人观点哈。
重量的确是一个最佳feature,但相应的应该有能识别这个feature的最简模式,如果专家们知道从重量来分辨肥皂盒,也许他们会整一个电子秤放在装配线上,然后继续使用机械臂取走那些未能达到一定重量的盒子。而小工也许还不一定拿风扇吹哈,把装配线弄斜一点就行了。

wanng fenng

unread,
Dec 5, 2008, 5:38:16 AM12/5/08
to pon...@googlegroups.com
我扩展一下这个问题,希望大家讨论一个更好的解决方式:

不但出现盒子是空的情况,还会出现两块香皂挤在一个盒子里边的情况(两块香皂都挤扁了);同时,流水线上拥挤了很多的盒子,即两个(或以上)盒子可能会齐头并进到达装配线的出口。

2008/12/5 Kenny Yuan <yuank...@gmail.com>

说到生产线,呵呵,有一个笑话是关于化繁为简的(虽然不一定真实)
虽然是笑话,但对设计者也应该有些启示吧

博士和小工的区别

据说这是真实的笑话,搏君一笑,看看什么叫资源浪费

话说联合利华新换了一批自动香皂包装机以后,经常出现香皂盒子是空的没有香皂的情况,而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不,一个由自动化,机械,机电一体化等专业的博士组成的Solution队伍来解决这个问题,没多久他们在装配线的头上开发了全自动的X光透射检查线,透射检查所有的装配线尽头等待装箱的香皂盒,如果有空的就用机械臂取走。

不巧,中国一乡镇企业生产香皂也遇到类似问题,老板吩咐线上小工务必想出对策决之,小工拿了一个电风扇放在装配线的头上,对着最后的成品吹之,空盒子被吹走,问题解决之.

--
Wang Feng
Purple Mountain Observatory,Chinese Academy of Sciences
2 West Beijing Road, Nanjing, China 210008

(+86)134 5189 5532 (+86)25 83332097

pongba

unread,
Dec 5, 2008, 5:28:26 AM12/5/08
to pon...@googlegroups.com


2008/12/5 樊帆 <fanfan1...@gmail.com>

工人日常所做的工作导致了他的思考模式必然是现实、低级的,但在检查空盒的方面却发挥了实效。
而专家因为工作原因,思考的思路必定是专业考究的,但却忽略了小技巧的现实效用。

你说的这个正是"心中有把锤子,所有东西看上去都是钉子"的扩展版啊 :-)

pongba

unread,
Dec 5, 2008, 5:09:09 AM12/5/08
to pon...@googlegroups.com


2008/12/5 Du Lei <dul...@gmail.com>
越是学历高,考虑问题的时候越容易划地自限。所谓拿这个锤子看见谁都像个钉子。

一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候,如果脑子里有一个与问题场景有某些相似性的既有方案,就会抑制不住地思维被该方案占满,很难实现fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法,为此也在阅读思维/认知科学方面的书,有一些heuristics能够有一定的作用,但是每每还是发现会思维落入盲点 :D


wanng fenng

unread,
Dec 5, 2008, 5:42:18 AM12/5/08
to pon...@googlegroups.com
2008/12/5 Du Lei <dul...@gmail.com>
越是学历高,考虑问题的时候越容易划地自限。所谓拿这个锤子看见谁都像个钉子。

一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候,如果脑子里有一个与问题场景有某些相似性的既有方案,就会抑制不住地思维被该方案占满,很难实现fresh的思考。
我发现google也有这样的问题:碰到问题第一个反应是google或者查找wiki关键词,而不是思考。 

Du Lei

unread,
Dec 5, 2008, 5:54:32 AM12/5/08
to pon...@googlegroups.com
这又让我想到另外一个问题,Google和Wiki上找到的往往是现成的解决问题的手段。这时候面临的问题其实不是Google的知识是否限制了我们的"思考",而是长期以来现成的解决方案,不去自己尝试解决问题是否限制了我们的"成长"。

我们都很清楚重新发明轮子的问题。但是往往重新把轮子发明一遍才能够真正理解轮子设计的方方面面,才有可能接触里面隐含的很多思想和思维方式。

2008/12/5 wanng fenng <wanng...@gmail.com>

pongba

unread,
Dec 5, 2008, 5:30:51 AM12/5/08
to pon...@googlegroups.com


2008/12/5 Yi Yang <sprite...@gmail.com>

重量的确是一个最佳feature,但相应的应该有能识别这个feature的最简模式,如果专家们知道从重量来分辨肥皂盒,也许他们会整一个电子秤放在装配线上,然后继续使用机械臂取走那些未能达到一定重量的盒子。而小工也许还不一定拿风扇吹哈,把装配线弄斜一点就行了。

恩恩,没错。其实Problem Solving的思维方法真是一个很复杂的学科。温伯格那本《你的灯亮着吗?》其实只是提供了一个不错的例子和几个在个别问题上有意义的heuristics,离真正的方法论还有很远。我一直也没看到这方面写得很好的方法论,《六顶思考帽》又显得宽泛了,泛泛而谈,没有让人一看有如心头明镜的感觉:(

樊帆

unread,
Dec 5, 2008, 6:05:48 AM12/5/08
to pon...@googlegroups.com
其实倒也不必担心"思考"的问题。
毕竟要站在巨人的肩膀上做事,当然对任何事情存疑是值得推崇的,不过也要注意"量",不过量即可,为了追究根源,会浪费很多精力和时间在次要的问题上。

我恰恰觉得"你的灯亮着吗?"就是要告诉我们注意深刻反思自己的立场和当前所处的"地方",走过了就倒回来几步,走慢就加快脚步。

pongba

unread,
Dec 5, 2008, 6:06:41 AM12/5/08
to pon...@googlegroups.com


2008/12/5 Du Lei <dul...@gmail.com>

这又让我想到另外一个问题,Google和Wiki上找到的往往是现成的解决问题的手段。这时候面临的问题其实不是Google的知识是否限制了我们的"思考",而是长期以来现成的解决方案,不去自己尝试解决问题是否限制了我们的"成长"。

我也有此感觉,我们很多时候评估一个方案的时候并不是根据"这个方案理论上已经无法再好"了来评价的,而是根据:

1) 这个方案能够满足我现在的要求,即便有缺点也并非不可忍受。
2) 我想不出更好的方案了。

横跨多个领域的牛人,诺奖得主 Herbert Simon 曾经对 1) 这个标准起名叫 Satisficing ("satisfy" and "suffice")。这个主观评价标准妨碍了人们进一步追求更好的,更符合手头问题的方案。有时候旁边拿来一个方案虽然不能完美契合,但是扭吧扭吧也就用了,看上去没问题(具体有多大问题,这个又涉及到个人对问题的洞察力了),在设计模式里面这样生搬硬套的例子应该是不少的,我一直觉得设计模式至今的讲授方式是个大问题,应该从问题的剖面出发,以问题解决的思维剥茧抽丝来介绍,最后提出的模式只是思考的结果,而不应该是"锤子"。

昨天在考虑论坛的信噪比解决方案的时候我自己也犯了 satisficing 和 confirming-bias 的问题,因为一开始 assume 没有妥善的解决办法来在当前论坛里解决噪音问题了(这个又是建立在之前对"首贴审核"功能的负面映像之上),所以后来一直都在集中考虑如何把 alternative 的方案完善,走了很远发现初始的步骤就没有考虑周全。之前对"首贴审核"功能的负面映像是建立在没有首页醒目提示和没有成员审核的前提下的,结果在我脑袋里面笼统地变成了"这个功能不可用",于是就把这个特性忽略了。False Assumption 是很可怕的。会员权限设置我以前也是用过的,但是没发现有什么用,于是又记成了"这个功能反正没啥用"..

lunar_lty

unread,
Dec 5, 2008, 6:22:51 AM12/5/08
to TopLanguage

> > TopLanguagehttp://groups.google.com/group/pongba- 隐藏被引用文字 -
>
> - 显示引用的文字 -


同意你的观点:."关键在于Architeture要善用两种不同的工具(望远镜和显微镜)."

Linker

unread,
Dec 5, 2008, 5:27:13 AM12/5/08
to pon...@googlegroups.com
我是反对CMM/CMMI那套东西的.
基于UML的OOP也是我不喜欢的.
那么软件设计是不是就是指OOP设计呢?
我想不是的.
不过国内的气氛就是OO至上主义吧.
软件设计不同于建筑的重要一点是,设计和实现无法高效分离.
如果做设计的人不去实现,那么设计必然不够"实现友好".
建筑行业的实现者的话语权和思考力不像程序员那么高.
所以可以分拆设计和实现.
软件的设计也是一个逐步求精的过程.
个人觉得,做软件和写书类似.
为什么没有人讨论写书的设计和实现分离?
几千年的历史证明大规模劳动密集型的"写书"是不可能的.




Regards,
Linker Lin
linker...@gmail.com


2008/12/5 Kenny Yuan <yuank...@gmail.com>

樊帆

unread,
Dec 5, 2008, 6:30:48 AM12/5/08
to pon...@googlegroups.com
> 同意你的观点:."关键在于Architeture要善用两种不同的工具(望远镜和显微镜)."

我来咬文嚼字一下,我始终觉得,把望远镜和显微镜比作工具,是不恰当的,我觉得用能力比较合适。差别在于,能力需要锻炼,而工具只需要到店铺买就行了。

就像上面说的,你会画UML图并不代表你就能画好UML图。UML是工具,而画好它所需要具备的素质则是能力。

樊帆

unread,
Dec 5, 2008, 6:35:57 AM12/5/08
to pon...@googlegroups.com
温伯格在《程序心理学》就已经指出开发团队的"战斗力"不是靠增加人手的,没有银弹的言论仍然有不过时

pongba

unread,
Dec 5, 2008, 6:43:42 AM12/5/08
to pon...@googlegroups.com


2008/12/5 Linker <linker...@gmail.com>
不过国内的气氛就是OO至上主义吧.

我相信这种现象不仅是 OO ,任何工具(包括知识)只要足够含糊或足够复杂都有可能变成大锤,用人们常用的词就是屁股决定脑袋了..

我不懂 OO, 我只懂解耦合的思想以及解耦合的具体思路(信息隐藏、封装,接口抽象,多态,etc .. )。

pongba

unread,
Dec 5, 2008, 7:06:50 AM12/5/08
to pon...@googlegroups.com
索性再转来杨军的另一篇相关的:

软件设计过程中的诱惑
2008-11-28 09:35
在软件设计的过程中,我们经常会面临这样的诱惑:

在工作过程中,突然出现了一个问题如鲠在喉,阻塞住了当前整个的工作进度,

而同时,你立刻能够想到一个快速搞定该问题的方案,这种情形下开发人员,很

容易就会受到快速解决问题的诱惑,快速地给出fix,然后继续推进到后面的内容,

维持那种开发过程中酣畅淋漓的快感。但是在开发过程中,不可避免会经常性地遇

到问题,如果经常性地给出快速的fix,到了一定的阶段,可能就会发现,现有的

系统处于一种补丁落补丁的状态,看上去不舒服,在这个不舒服的基础上作后续

的开发也很难受。如果一定要继续坚持维持这个不够好的设计,也许,最终产品

还是能够开发完成,但是它的扩展性,稳定性,可复用性,可修改性都会大打折扣



这种对问题快速给出fix的方式,在产品维护的阶段,尚可运用,当然前提是产

品本身的架构设计得足够好。但是在产品的设计阶段,在早期开发阶段,还使用

这种方式,则可能会带来较大的负面影响。


这样的体验,最近自己就有这一回。

最近一直在设计一个处理语意部分的evaluator,期间也遇到了不少问题。初始

给出的设计在后续的实现环节中发现有一些局限,但是在实现的过程中因为过于关

注进度,也在一定程度上受到持续推进的顺畅感的诱惑,自己并没有停顿下来审视

原先的设计,而是稍作思考,给出一个快速的fix,能够解决当前的需要之后,就

继续进行到后续的开发中
。虽然在编码的过程中,已经感觉到有些底层数据结构设计的

实在谈不上舒服,为了解决设计问题,引入coding trick的场景也不只一处,但

是身陷其中,并没有想过站起来,从更高的角度进行思考。及至代码基本编写完毕

,开始测试,暴露出一些bug,需要进行修改的时候,才更充分地体会到现有的设计

的局限性以及这种局限性给维护和扩展带来的开销。这样束手束脚地调试了差不多

一周的时间,基本功能倒是调通了,但是有些不爽的是,这种调通的感觉完全是建立

在调试经验之上的,刨开调试的经验和fix的一些bug,从流程上和框架上来看,自己

对现有的这个版本实现的品质并没有太大的信心,简单来说,让自己闭上眼想一想,

现在的这个设计,这个实现,在品质上是不是达到了自己的要求,是不是在自己的控制

范围内,还是一件说不太清楚的事情
。对于一个工业级的软件产品来说,这种控制感实

在是太虚弱了。考虑了一天,跟老大也沟通了一下,决定对evaluator进行重构。从底

层的数据结构的定义,到基本的流程框架,乃至具体的实现,几乎全部要作一番调整。

短期来看,这种调整会给进度带来一定的影响,但是在项目的初期阶段,对于根基性的

东西,还是值得花费较多的资源作精作细,这样后续的开发才可能有一个良好的基础。


P.S. 这段时间一个比较深的体会就是,当你感觉需要实现的某个模块过于复杂,条理

不是非常清晰,或是需要引入特殊的coding技巧来解决一个问题的时候,往往意味着更高

层次上的设计和架构潜伏着问题,所以这种时候,要控制住埋头实现复杂逻辑,引入trick

快速解决问题的冲动,缓冲一下,站起来,审视一下,是不是可以从更高的层次来简化问

题,给出更好的设计,消除引入特殊trick的必要性。

樊帆

unread,
Dec 5, 2008, 7:28:03 AM12/5/08
to pon...@googlegroups.com
我觉得杨军如果可以把实际的开发代码拿出来按时间顺序先后解剖分析,或许可以给我们大家的思考带来不错的锻炼呢。不过如果因为商业机密而不便拿出也没办法。

wanng fenng

unread,
Dec 5, 2008, 7:33:10 AM12/5/08
to pon...@googlegroups.com


2008/12/5 樊帆 <fanfan1...@gmail.com>

其实倒也不必担心"思考"的问题。
毕竟要站在巨人的肩膀上做事,当然对任何事情存疑是值得推崇的,不过也要注意"量",不过量即可,为了追究根源,会浪费很多精力和时间在次要的问题上。

我更担心的是创新问题。

最近一直在看量子力学,狄拉克将近80年前出的量子力学圣经中,漂亮的数学架构实在是令人叹为观止,如果他出生在我们这个时代,有google可以找到别的数学家的方案,估计现在还在象我一样,忙着推导别人的理论架构吧,狄拉克方程能否问世实在是问题。现在的知识累积实在太多了,一个人很难穷尽一个分支的所有,什么时候该收集资料,什么时候自起炉灶很难判断的说。

Yi Yang

unread,
Dec 5, 2008, 9:03:24 AM12/5/08
to pon...@googlegroups.com
其实1)是容易达到的状态,总能找到一个可接受的解。但是2)就不是很好判断了:难道我就满足于这一个解了吗?难道就没有更优解存在了吗?目前这个解是否还有改进的余地?
 
到底大脑是如何决定将目前得到的可接受解继续执行下去的?个人觉得杨军谈到的"维持那种开发过程中酣畅淋漓的快感"还是没能说得很清楚。感觉有些像《影响力》里面说到的保持一致性。

 
2008/12/5 pongba pon...@gmail.com

Rui

unread,
Dec 5, 2008, 9:29:40 AM12/5/08
to TopLanguage
OO是手段,不是目的.
模式是起点,不是终点.
工具是为人所用的,不是奴役人的.
我教导手下的SA时,以上几点就是反复强调的.

实际上我在这行业混了十几年的结论就是,CS本身革命性的变化非常少,本质上都是相通的,甚至还有思想回潮(就是十几年前的东西突然流行起来,比如重
构).

On 12月5日, 下午7时43分, pongba <pon...@gmail.com> wrote:
> 2008/12/5 Linker <linker.m....@gmail.com>

Rui

unread,
Dec 5, 2008, 9:32:55 AM12/5/08
to TopLanguage
"开发过程中酣畅淋漓的快感"
这个很难形诸文字的.你在做出一个良好的设计时,自然会有这种感觉的.其实对于一个优秀的Architecture,这种对于好的架构味道的嗅觉是基
础.

Rui

unread,
Dec 5, 2008, 9:36:08 AM12/5/08
to TopLanguage
我从杨军的这篇文章能够感觉到,这是一个非常优秀的Architecture.
我觉得一个优秀的Architecture有一个基本的素质,就是对于不良架构的敏感嗅觉,就是说对于一种不理想的结构,有一种天生的感觉浑身不舒服的
感觉.
只有有了这个感觉才知道应该去修正,还有如何去修正.

另外,他所说的"开发过程中酣畅淋漓的快感",我也是深有体会,确实是一种非常有成就感的感觉.好象做了一个好设计以后,一天都觉得非常开心,看外面的
天都觉得更加蓝了的感觉.哈哈.

On 12月5日, 下午8时06分, pongba <pon...@gmail.com> wrote:
> 索性再转来杨军的另一篇相关的:
>
> 软件设计过程中的诱惑
> 2008-11-28 09:35
> 在软件设计的过程中,我们经常会面临这样的诱惑:
>
> 在工作过程中,突然出现了一个问题如鲠在喉,阻塞住了当前整个的工作进度,
>
> 而同时,你立刻能够想到一个快速搞定该问题的方案,这种情形下开发人员,很
>
> 容易就会受到快速解决问题的诱惑,快速地给出fix,然后继续推进到后面的内容,
>
> 维持那种开发过程中酣畅淋漓的快感。但是在开发过程中,不可避免会经常性地遇
>
> 到问题,如果经常性地给出快速的fix,到了一定的阶段,可能就会发现,现有的
>
> 系统处于一种补丁落补丁的状态,看上去不舒服,在这个不舒服的基础上作后续
>
> 的开发也很难受。如果一定要继续坚持维持这个不够好的设计,也许,最终产品
>
> 还是能够开发完成,但是它的扩展性,稳定性,可复用性,可修改性都会大打折扣
>
> 。
>

> *这种对问题快速给出fix的方式,在产品维护的阶段,尚可运用,当然前提是产
>
> 品本身的架构设计得足够好。但是在产品的设计阶段,在早期开发阶段,还使用
>
> 这种方式,则可能会带来较大的负面影响。*


>
> 这样的体验,最近自己就有这一回。
>
> 最近一直在设计一个处理语意部分的evaluator,期间也遇到了不少问题。初始
>
> 给出的设计在后续的实现环节中发现有一些局限,但是在实现的过程中因为过于关
>
> 注进度,也在一定程度上受到持续推进的顺畅感的诱惑,自己并没有停顿下来审视
>
> 原先的设计,而是稍作思考,给出一个快速的fix,能够解决当前的需要之后,就
>
> 继续进行到后续的开发中。虽然在编码的过程中,已经感觉到有些底层数据结构设计的
>
> 实在谈不上舒服,为了解决设计问题,引入coding trick的场景也不只一处,但
>
> 是身陷其中,并没有想过站起来,从更高的角度进行思考。及至代码基本编写完毕
>
> ,开始测试,暴露出一些bug,需要进行修改的时候,才更充分地体会到现有的设计
>
> 的局限性以及这种局限性给维护和扩展带来的开销。这样束手束脚地调试了差不多
>
> 一周的时间,基本功能倒是调通了,但是有些不爽的是,这种调通的感觉完全是建立
>
> 在调试经验之上的,刨开调试的经验和fix的一些bug,从流程上和框架上来看,自己
>
> 对现有的这个版本实现的品质并没有太大的信心,简单来说,让自己闭上眼想一想,
>
> 现在的这个设计,这个实现,在品质上是不是达到了自己的要求,是不是在自己的控制
>
> 范围内,还是一件说不太清楚的事情。对于一个工业级的软件产品来说,这种控制感实
>
> 在是太虚弱了。考虑了一天,跟老大也沟通了一下,决定对evaluator进行重构。从底
>
> 层的数据结构的定义,到基本的流程框架,乃至具体的实现,几乎全部要作一番调整。
>
> 短期来看,这种调整会给进度带来一定的影响,但是在项目的初期阶段,对于根基性的
>
> 东西,还是值得花费较多的资源作精作细,这样后续的开发才可能有一个良好的基础。
>

> *P.S. 这段时间一个比较深的体会就是,当你感觉需要实现的某个模块过于复杂,条理


>
> 不是非常清晰,或是需要引入特殊的coding技巧来解决一个问题的时候,往往意味着更高
>
> 层次上的设计和架构潜伏着问题,所以这种时候,要控制住埋头实现复杂逻辑,引入trick
>
> 快速解决问题的冲动,缓冲一下,站起来,审视一下,是不是可以从更高的层次来简化问
>

> 题,给出更好的设计,消除引入特殊trick的必要性。*

一首诗

unread,
Dec 5, 2008, 9:36:29 AM12/5/08
to TopLanguage
OO至少有一个好处,有很多很多人在使用它,人们为它创造了很多的工具、方法和经验的总结。

我一直以来主要工作是用C做的,感觉就是,设计非常的套路化,就一个原则——封装。
将系统大致分成几个模块,定义一下接口,就拉倒了。
没有多态,没有继承,没有设计模式,没有Abstract Class,没有Interface,没有Exception……
画出来的设计图就是几个方框框,A调用B在调用C……

只用两种数据结构:数组和hash,甚至都不准用链表;公然鼓吹拷贝代码是最安全高效的开发方法……

当然C也可以模拟出这些来,但用起来总是不那么自然,而且会遇到同事的抵触。


On 12月5日, 下午7时43分, pongba <pon...@gmail.com> wrote:
> 2008/12/5 Linker <linker.m....@gmail.com>
>

Kenny Yuan

unread,
Dec 5, 2008, 9:38:59 AM12/5/08
to pon...@googlegroups.com
个人认为,关于OO优劣的讨论不符合此话题。本话题名为《关于软件架构设计的思考

Rui

unread,
Dec 5, 2008, 9:39:44 AM12/5/08
to TopLanguage
我觉得这是个"为我所用"问题,就我感觉,一切学术问题万万不能有崇拜之感.我在学习之时,对于一切理论,第一感觉都是在想,我如何去驳倒他..只有在
无法驳倒时才会接受.国内目前的教育过于注重学习及接受,而少有自己思维.

On 12月5日, 下午8时33分, "wanng fenng" <wanng.fe...@gmail.com> wrote:
> 2008/12/5 樊帆 <fanfan19830...@gmail.com>


>
> > 其实倒也不必担心"思考"的问题。
> > 毕竟要站在巨人的肩膀上做事,当然对任何事情存疑是值得推崇的,不过也要注意"量",不过量即可,为了追究根源,会浪费很多精力和时间在次要的问题上。
>
> 我更担心的是创新问题。
>

> 最近一直在看量子力学,狄拉克将近80年前出的量子力学圣经中,漂亮的数学架构实在是令人叹为观止,如果他出生在我们这个时代,有google可以找到别的数学 家的方案,估计现在还在象我一样,忙着推导别人的理论架构吧,狄拉克方程能否问世实在是问题。现在的知识累积实在太多了,一个人很难穷尽一个分支的所有,什么时 候该收集资料,什么时候自起炉灶很难判断的说。

Kenny Yuan

unread,
Dec 5, 2008, 9:31:56 AM12/5/08
to pon...@googlegroups.com
关于引文中提到的"具体的思维方法",友情提供一个candidate:

许多知识在接受时是这个样子的:"同学们,今天我们来讲xxxx,xxxx有四个特性,分别为A、B、C、D;关于xxxx有3个定理,分别为Alpha/Beta/Gamma……好的,下面我们开始做题……"

我认为:如果一个人的思维习惯了这种学习方式,知识很容易会成为负担(我个人认为:在中国上过学的,思维大约都会有一定比例受此影响)

在讲授知识时,应该更多地引入这些样的"起源问题",比如:
1、定理的提出是为了解决什么问题?
2、如此设计的动机是因为什么?
3、器官进化成这样是为了适应什么?优势在哪?
4、这个keyword为什么会出现?其历史原因(背景)是什么?
5、关于此定律的历史争论是因为什么?各自出于什么目的?
6、历史上的错误(悖论)是怎么出现的?是如何解决的?
7、关于这种原则,人们常见的误解和错误使用是什么样的?
8、这种理论是什么时候出现的,当时的社会/科学背景是什么样的?理论之前和之后,带给世界的变化是什么样的?没有它的时候是如何解决问题的?
……

有时候,我们在看一些趣闻逸事(也可称为8卦)的时候,会突然发现"原来是因为这个原因啊!",感觉"终于理解了"。为什么会有这种情况?因为我们用错误的(至少不完备的)方式来接受了知识。

话题扯回来,如果对每种已知方案,我们都熟知它的应用场合/长处/短处/关联/限制/隐藏的好处/额外的损失/等等……,就有可能得心应手地使用已知方案,减少它们对更优解的思维干扰(非充分条件)

2008/12/5 pongba <pon...@gmail.com>
2008/12/5 pongba <pon...@gmail.com>

一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候,如果脑子里有一个与问题场景有某些相似性的既有方案,就会抑制不住地思维被该方案占满,很难实现fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法,为此也在阅读思维/认知科学方面的书,有一些heuristics能够有一定的作用,但是每每还是发现会思维落入盲点 :D

但另一方面,没有知识又真的很难思考。很多时候方案难以完全逆向导出,而是通过联想发现某个既有知识能够被用来解决手头问题的。

我想最终的方案肯定是critical的接受知识,critical的思考。具体的思维方法还在不断反思中..

SpitFire

unread,
Dec 5, 2008, 9:14:50 AM12/5/08
to pon...@googlegroups.com
这就是重构的一个意义,那就是不能欠下技术债,要不停的使用重构来使设计和实现能很好的解决当前的问题,欠债越多越久,以后还起来就越困难,成本越高。bob大叔在agile社区的发怒贴主要也是说的这个问题。

2008/12/5 pongba <pon...@gmail.com>

P.S. 这段时间一个比较深的体会就是,当你感觉需要实现的某个模块过于复杂,条理

不是非常清晰,或是需要引入特殊的coding技巧来解决一个问题的时候,往往意味着更高

层次上的设计和架构潜伏着问题,所以这种时候,要控制住埋头实现复杂逻辑,引入trick

快速解决问题的冲动,缓冲一下,站起来,审视一下,是不是可以从更高的层次来简化问

题,给出更好的设计,消除引入特殊trick的必要性。


--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba



--
SpitFire

一首诗

unread,
Dec 5, 2008, 9:46:30 AM12/5/08
to TopLanguage
如果没有手段,如何达到目的?
如果没有一个起点,如何迈出向终点的第一步?
如果不去学习工具,自然不会被工具奴役,但是否也失去了使用工具的机会?

思想的回潮,是时尚界几年一次注定的轮回,还是因为时移世易,旧的方法有了存在的理由?又或者多年的发展之后,当年的天方夜谭,到现在终于有了实用的价
值?

soker

unread,
Dec 5, 2008, 9:53:04 AM12/5/08
to TopLanguage
看了大家的回贴,讲得都挺好的.个人觉得关于软件架构方面,还有个重要方面,就是节奏把握.
架构往往承载着很多人的工作量,如何把握统一的节奏,对于项目或者软件的成功至关重要. 架构师就象乐团的指挥家,他一有问题,出来的结果就不是美妙音
乐了.

Rui

unread,
Dec 5, 2008, 10:02:47 AM12/5/08
to TopLanguage
嗯.既然提到这个空盒子的.
我也讲一个吧,也算Problem solving话题之一好喽.

飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
简言之,就是高速时后掠角增大.低速时后掠角减小.

在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.

苏联人的设计令人崩溃的简单.
内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.

我讲这个故事,落实到架构设计,我想说明的是,一个优秀的架构师的本事在于简化模型.只有模型简化了,才会有一个好的实现.如果在架构阶段模型就复杂的
不得了,那基本上不大指望后面的design和coding能做好.

至于Problem Solving,我觉得这是一个典型的80-20法则的应用....美国人的设计好不好?应该说是好的.但苏联人的设计用20%的
代价解决了80%的问题.


On 12月5日, 下午5时53分, pongba <pon...@gmail.com> wrote:
> 2008/12/5 Kenny Yuan <yuankain...@gmail.com>
>
> > *
> > 话说联合利华新换了一批自动香皂包装机以后,经常出现香皂盒子是空的没有香皂的情况,而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不,一个由自 动化,机械,机电一体化等专业的博士组成的Solution队伍来解决这个问题,没多久他们在装配线的头上开发了全自动的X光透射检查线,透射检查所有的装配线 尽头等待装箱的香皂盒,如果有空的就用机械臂取走。
>
> > 不巧,中国一乡镇企业生产香皂也遇到类似问题,老板吩咐线上小工务必想出对策决之,小工拿了一个电风扇放在装配线的头上,对着最后的成品吹之,空盒子被吹走,问 题解决之.
> > *
>
> 这个我也听过,印象很深刻,这次你贴出来之后我又想,从机器学习的角度来看,这个小工的 feature selection
> 做得非常棒,因为这本质上是一个分类问题,只要摸到那个对于区分最关键的 feature 就事半功倍了,而小工 select 出来的这个 "重量"
> 就是一个最佳 feature 。

pongba

unread,
Dec 5, 2008, 10:07:07 AM12/5/08
to pon...@googlegroups.com


2008/12/5 SpitFire <spit...@gmail.com>

这就是重构的一个意义,那就是不能欠下技术债,要不停的使用重构来使设计和实现能很好的解决当前的问题,欠债越多越久,以后还起来就越困难,成本越高。bob大叔在agile社区的发怒贴主要也是说的这个问题。

uncle bob 这个帖子有意思!呵呵:)

Rui

unread,
Dec 5, 2008, 10:11:45 AM12/5/08
to TopLanguage

OO只是一种手段,PP,FP都是替代之一.所以我说OO不是目的.OO只是从问题域到解域的一种办法而已.对于架构师来说,他必然不是纯OO的.
Pattern就是一个良好的起点,各种模式告诉我们如何开始,有如围棋的定式一样.我们从定式开始,但并不是为了把棋下成定式那个样子.
为了不被工具奴役,你需要知道工具的本质,知道他的优点和缺点.
在架构师眼里,技术无优劣之分,只有特定的环境才能判断设计的好坏.
你认为过程式方法过时么?在特定的情况下过程式比OO要有力的多.
思想的回潮,我觉得是由于控制CS走势的,其实只有几个关键的元要素,不管以什么样的技术形式出现,决定性的东西其实只有那么几个...
这个我一直在思考,我想这也是冯诺依曼体系的本质在控制着软件技术的走势.这就好象我们在欧氏几何中,用四至五条公理推导出了一大堆的不同理论一样.
什么是冯诺依曼体系的几大公理.我这几年一直在思考,可惜还没有什么突破性的东西.
Martin Fowler的那本企业架构模式(PEAA),我从一开始就不是从应用的角度去读,而是试图从基础理论的角度去思考,希望能有突破.

xxmplus

unread,
Dec 5, 2008, 10:13:35 AM12/5/08
to pon...@googlegroups.com
说起美国和苏联,想起了那个水笔和铅笔的笑话

2008/12/6 Rui <cao...@gmail.com>:

--
Any complex technology which doesn't come with documentation must be the best
available.

pongba

unread,
Dec 5, 2008, 10:14:32 AM12/5/08
to pon...@googlegroups.com


2008/12/5 Rui <cao...@gmail.com>

飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
简言之,就是高速时后掠角增大.低速时后掠角减小.

在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.

苏联人的设计令人崩溃的简单.
内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.

我觉得这个例子很赞。我对它的理解是,美国飞行员在计划一开始就犯了false assumption的错误,先入为主的假定了一定要用自动的,也许是因为他们太"高级工程师"了。Anyway,如果一开始的时候能够做横向的思考,众人头脑风暴,应该很容易侦测出犯下的false assumption错误,因为每个人的视角不一样。

Rui

unread,
Dec 5, 2008, 10:18:05 AM12/5/08
to TopLanguage
我看了杨军的那几篇文章.很同意他关于问题理解的一些观点.
我这个例子里的苏联设计师,我认为从软件架构师的角度讲,他也必定是一个很牛的架构师,因为他会简化问题.
我有一个观点,就是真正的大牛在讲述自己的工作时,能够用不到100字让一个完全没有了解的人清楚自己的工作的意义.
这其实也是一种抓住本质的能力,也是一种复杂模型简单化的能力.
如果架构师不会简化模型,那下面接着的designer和coder就等着受罪吧...
就象MiG-23团队一样,如果不是架构师给出一个很好的变后掠翼实现架构,那后面的具体设计人员和工艺人员就死去吧(苏联当时的工艺水平和制造水平都
与美国有很大的差距)

Rui

unread,
Dec 5, 2008, 10:28:50 AM12/5/08
to TopLanguage
嗯.同意你的分析.
我结合下具体的架构师的工作展开讨论.
其实这种事情,在架构师的工作中也是非常重要的,就是区别真正的需求和pongba所讲的false assumption.
对于架构师来说,用户的话,不能完全当作需求.这一点非常重要.
我们可以想象一下,当初开会时,美国飞机员对着F101的设计师描述他的需求时可能是这样说的:
先生,我想你知道,我需要这样的飞机,当它飞行在高空中,需要高速突防时,他得有很好的速度,哦,就是后掠角较小的状态..象XX型号一样.
但我在空中缠斗时,要求他有很好的机动性,那时候我希望他象YY型号一样.

美军的这个设计师就想.噢.他要的是一自动可变后掠翼的飞机...
于是,错误就开始了.

从架构师的专业角度讲,这个设计师犯了什么错误呢?
架构师所接触的第一份材料,就是客户的需求,而在架构师的工作准则中,有一点就是需求与实现分离.时刻要防止把实现的因素带到需求里来.
这个案例符合典型错误,因为飞机员的真实要求,实际上是高空高速和缠斗时的高机动性.飞行员在描述时,自己设想了一些实现方式(自动变后掠翼),这一点
被设计师误解后带入到了设计和制造中.
这在软件中更常见,尤其是一些对于软件略有了解的客户,在描述需求时,可能会告诉你,嗯.我想用一个TAB页,然后上面有几个按钮,某一个按钮按下去后
会XXXYYY.之类的.

如果架构师没有良好的过滤的话,这些false assumption就会错误的引入到设计中来,可能导致用户真实的需求被掩盖起来了.
这个时候出问题架构师真的可能很委屈,不是你说要XXXX的么.现在又怪我...客户可能就怒了...是我设计还是你设计...于是架构师气
绝....


On 12月5日, 下午11时14分, pongba <pon...@gmail.com> wrote:
> 2008/12/5 Rui <cao...@gmail.com>
>
> > 飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
> > 那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
> > 简言之,就是高速时后掠角增大.低速时后掠角减小.
>
> > 在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
> > 美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
> > 系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.
>
> > 苏联人的设计令人崩溃的简单.
> > 内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
> > 这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.
>
> 我觉得这个例子很赞。我对它的理解是,美国飞行员在计划一开始就犯了false

> assumption的错误,先入为主的假定了一定要用自动的,也许是因为他们太"高级工程师"了。Anyway,如果一开始的时候能够做横向的思考,众人头脑 风暴,应该很容易侦测出犯下的false

pongba

unread,
Dec 5, 2008, 10:29:58 AM12/5/08
to pon...@googlegroups.com


2008/12/5 wanng fenng <wanng...@gmail.com>
不但出现盒子是空的情况,还会出现两块香皂挤在一个盒子里边的情况(两块香皂都挤扁了);同时,流水线上拥挤了很多的盒子,即两个(或以上)盒子可能会齐头并进到达装配线的出口。

一个问题的出现是诸多因素组合作用的结果,多个必要前提合取的结果。改变任何一个或多个前提也许就解决了问题,所以我想这里的信息不足,如果是我的话第一步是考察装配线是具体怎样导致香皂挤在一块的,从源头上试着解决问题。

除此之外还可以打补丁,比如用电风扇吹走空盒子就是打补丁方案,不去解决空盒子产生的根源,而是后期将其去掉。具体到这个问题,如果两块香皂的情况少见的话,直接称出来扔掉就可以了 :D

一首诗

unread,
Dec 5, 2008, 10:30:13 AM12/5/08
to TopLanguage
我没有觉得过程方法过时啊。我只是不知道在这种方法下能做到什么程度,应该怎么样去从问题域走到解决域。在我的判断中,我所遇到的问题,用OO的方式去
抽象,会更容易一些。我们一直都用C,而且是最基本的C,并不是一个技术问题,而是一个历史问题。

我所参与过的例子,都过于简单或者说粗糙。而市面上大多数的东西都是从OO的角度谈问题的解决方法的,同样对我没有帮助。我不是“必然不是纯OO的”,
我是被迫做纯PP的。

有的时候看各位这样的高手讨论,有一种修炼到了很深的地步,看穿一切迷雾,飞花摘叶皆可伤人的地步。所以有没有兵器对你们来说没有什么区别了。

可是我觉得对小兵来说,手中有没有兵器,区别还是挺大的。

另外,我觉得CS毕竟只是Engineering,和纯智力的公理体系去推演还是有很大不同吧。

就像Knuth说过(大意),他能证明一段程序是正确的,但他不能保证这段程序可以工作啊

一首诗

unread,
Dec 5, 2008, 10:34:18 AM12/5/08
to TopLanguage
http://tech.sina.com.cn/d/2005-02-23/0824532626.shtml

这是个”寓言“故事哦。

Kenny Yuan

unread,
Dec 5, 2008, 10:38:30 AM12/5/08
to pon...@googlegroups.com
那不是个故事,虽然国家的名字流传得混乱了。

那种笔后来上市了,用于在野外、沙漠、严寒、水下、高海拔等条件下书写——当然,是用在地球上 :)

2008/12/5 一首诗 <newp...@gmail.com>

http://tech.sina.com.cn/d/2005-02-23/0824532626.shtml

这是个"寓言"故事哦。

On 12月5日, 下午11时13分, xxmplus <xxmp...@gmail.com> wrote:
> 说起美国和苏联,想起了那个水笔和铅笔的笑话
>

Rui

unread,
Dec 5, 2008, 10:45:59 AM12/5/08
to TopLanguage
举个例子说,一般来说,讲算法的课程,恐怕很少弄成OO的,多数还是过程式的...
你要做个整型数的快排都要搞出N个类来,怎么也是叠床架屋了.
我的意思是想说,OO也是有其局限性的.PP并非一定就不适合.
你说的CS是Engineering,那当然了.但这不妨碍我们去探究它的本质呀.就象中国古代造个亭子,工匠有很多歌诀.不需要什么公式就能造出又好
看又稳固的亭子.但你用数学和力学去分析一下,就会发现这个Engineering有其很深厚的理论基础的.
所以我也在思考,CS,尤其是软件技术的思想回潮其背后的理论基础是什么.

Kenny Yuan

unread,
Dec 5, 2008, 10:48:12 AM12/5/08
to pon...@googlegroups.com
http://spacepen.cn/ -- 太空笔的中国官网

一篇文章
http://scitech.people.com.cn/GB/41163/3196006.html

全文贴于此(文中粗体是我加的):

再探发明史:太空笔的传奇

作者:方舟子

有一个流传甚广的故事:美国科学家们想研制一种在太空失重情况下使用的太空笔,可研究了好长时间都没有成功,只好向全国发出了征集启事,收到了一位小学生寄来的包裹,写着一行字:"能否试试这个?"打开一看,是一大把铅笔。

这个故事想告诉人们,有时看上去很复杂的问题,其实有极简单的现成解决办法。这当然是很有教育意义的,可惜它是捏造出来的。

早期的宇航员都使用铅笔,并不是因为接受了小学生的建议,而是因为钢笔、圆珠笔在失重条件下都无法使用,铅笔是惟一的选择。但是铅笔笔芯有时候会断,在失重的环境中飘浮,会飘进鼻子、眼睛中,或飘进电器中引起短路,成了危险品。此外,铅笔的笔芯和木头在纯氧的环境中还会快速燃烧。

因发明了圆珠笔通用笔芯而发了大财的保罗·费舍尔,意识到宇航员使用安全、可靠的书写工具的迫切性,自掏腰包进行研制,花了两年时间和两百万元费用后,于 1965年研制成了能在太空环境下使用的圆珠笔———太空笔。其原理很简单,采用密封式气压笔芯,上部充有氮气,靠气体压力把油墨推向笔尖。经过严格的测试后,太空笔被美国宇航局采用。1967年12月,费舍尔以每枝2.95美元的价格把400枝太空笔卖给美国宇航局。

1969年7月 20日,太空笔跟随阿姆斯特朗和奥尔德林上了月球,并救了他们的命。阿姆斯特朗和奥尔德林在月球表面完成历史性漫步,回到登月舱准备离开时,发现发动机的塑料手动开关被宇航服的背囊碰断,无法启动发动机向地面指挥中心求援。他们需要拨动开关中一个细小的金属条,为了减轻重量,他们已抛弃了所有的工具。地面指挥中心的一名工程师灵机一动,建议他们用太空笔试试。奥尔德林掏出太空笔,缩回笔芯,用笔的中空尾端拨动了开关,成功地启动了登月舱的发动机。

太空笔是全天候的圆珠笔,除了太空环境,还可在其他各种极端恶劣(如寒冷的高山上和深海底)的条件下使用,如油污、潮湿、粗糙、光滑的表面,并适用于各种角度书写,使用寿命长达几十年,深受登山运动员、户外活动者、技工、士兵、警察的欢迎。目前在美国市场上8美元即可买到一枝最简单的费舍尔太空笔。

奇怪的是这个富有传奇色彩的太空笔却成了谣言的对象,备受嘲笑,成了愚蠢的象征。有人说美国人花巨资开发太空笔完全没有必要,不如像前苏联宇航员那样简单地使用铅笔(实际上,前苏联宇航员后来也改用费舍尔太空笔)。还有人干脆说太空笔从来就没有研制出来过。直到最近,还有人在学术会议上把这个谣言进行添油加醋,开发费用被他们夸大了5000倍:

"'为了研究在太空环境下圆珠笔能出水,竟使科学家花费了100亿美元,终了却毫无结果。最后得知,铅笔在太空环境下就能写出字。'11月3日,在中国农业大学召开的'2004年全国农林研究生教育发展论坛'上,一位专家将这则黑色幽默娓娓道来,各大学领导和专家对'研究要切合实际,尤其是以前沿研究为主的研究生教育更是如此'的观点表示认同。"(《中国农大研究生教育创新性"学科群落"质高多产》,《中国教育报》2004年11月7日第1版)

费舍尔太空笔中国市场上也买得到,叫"飞梭太空笔",许多百货大楼、礼品店均有销售,与会专家竟然没有一个人见过、听说过?"研究要切合实际",说得一点也不错,首先就要从自己做起。

Kenny Yuan

unread,
Dec 5, 2008, 10:33:33 AM12/5/08
to pon...@googlegroups.com
看到了飞机二字,想起了一些有趣的例子:
(相信例子后面的理念大家看过后都会明白,所以就保持此邮件的简洁,不再多废话了)

1、米国的最新高科技军用飞机试飞,飞行员在跑道上指示电脑将起落架收起来。结果飞机被摔坏了。
(因为电脑没有限制此指令的使用条件)

2、商务飞行中的客机,在降落时,反推器不起作用。飞机冲出跑道(这个例子不再有趣,因为有人KIA)
(因为设计时,反推器的使用有限制条件,但是因为气候原因,系统错误地认为此时不能使用反推器)

一首诗

unread,
Dec 5, 2008, 11:00:07 AM12/5/08
to TopLanguage
我想,真正的工程设计,特别是像飞机研究这样耗资巨大的工程,其决策过程,未必会这么简单的。草草看了一点这个故事的资料,看到一句话:

The limitation of the wide spacing, however, was that it reduced the
benefits of variable geometry as much as it reduced their technical
difficulties.

美国人实际上首先搞出来了F111这种世界上第一个量产的Variable-sweep wing战机。他们做设计的时候,真的不曾想到过mig-23
的简化版本么?

未必。

也许他们权衡了之后,觉得F111这种方案才是最适合美国人的——他们有钱,有技术,可以把Variable Geometry Swing的优点发挥
到最高,而不需要用一个简化版的方法赶时间。

(当然我也是猜的,也许真的就是他们一时头脑不清)

也许设计和生活中相当多的事情一样,就是一个在很多因素之间trade-off的过程,只有better后worse,没有perfect的解决方
案。

进度、人力、历史因素、执行者的能力、个性、市场、老板的意见、心情……设计从来不光是一个纯technical的问题。

Rui

unread,
Dec 5, 2008, 11:03:10 AM12/5/08
to TopLanguage
噢.恐怕你是搞错了.MiG23当然在F111之前呀....当然,这个事有一个原因是美国人不认为MiG23这种可变后掠翼是真正的可变后掠翼,,,
所以认为F111是第一个吧.
我映像里同期美国搞的不是F111吧,好象是F101?我查一下去.

On 12月6日, 上午12时00分, 一首诗 <newpt...@gmail.com> wrote:
> 我想,真正的工程设计,特别是像飞机研究这样耗资巨大的工程,其决策过程,未必会这么简单的。草草看了一点这个故事的资料,看到一句话:
>
> The limitation of the wide spacing, however, was that it reduced the
> benefits of variable geometry as much as it reduced their technical
> difficulties.
>
> 美国人实际上首先搞出来了F111这种世界上第一个量产的Variable-sweep wing战机。他们做设计的时候,真的不曾想到过mig-23
> 的简化版本么?
>
> 未必。
>

> 也许他们权衡了之后,觉得F111这种方案才是最适合美国人的----他们有钱,有技术,可以把Variable Geometry Swing的优点发挥


> 到最高,而不需要用一个简化版的方法赶时间。
>
> (当然我也是猜的,也许真的就是他们一时头脑不清)
>
> 也许设计和生活中相当多的事情一样,就是一个在很多因素之间trade-off的过程,只有better后worse,没有perfect的解决方
> 案。
>

> 进度、人力、历史因素、执行者的能力、个性、市场、老板的意见、心情......设计从来不光是一个纯technical的问题。

Jian Wang

unread,
Dec 5, 2008, 11:06:20 AM12/5/08
to pon...@googlegroups.com
对于构架来说,我觉得难点在于对于前瞻性的把握。
每个软件在开发前,都会有大量的美好愿景,有大量的迷人功能要实现。
但是如果过多的考虑V2,V3等后续版本中可能会引入的功能,那么显然会造成巨大的额外开发负担,并且会使得构架过分复杂。
但是如果在将来发现要实现某个特性时,需要对构架大动干戈,甚至只是修一个BUG,也有可能涉及到构架的问题,那么显然也是巨大损失。
想要找一个在初期足够简单,又有足够发展潜力的方案,真的是很难。

Rui

unread,
Dec 5, 2008, 11:11:02 AM12/5/08
to TopLanguage
嗯.这是个实际问题.
我觉得最主要的,是在于认识这个系统的本质.所谓模型的简化,其实就是将模型本质化.如果你保留了系统的本质化的东西,那么即使是简化了,在V2和V3
也不太应该出现颠覆性的东西.
当然了,这对于架构师来说本身就是挑战,架构师工作的魅力也就在于这种不能公式化的工作.

一首诗

unread,
Dec 5, 2008, 11:11:27 AM12/5/08