{转载} 关于软件架构设计的思考 by 杨军(yangjunpro)
pongba
杨军之前在 TopLanguage 上只发了三个主题，但字字珠玑：
[1] 有些事情做起来比想象中容易。
[2] 有关读书方法的一点想法。
[3] 一件事情如果你没有说清楚，十有八九不能做好。
以下是 "关于软件架构设计的思考" 的正文
--------
最近在重构设计。这一回自己吸取了之前的教训，在想清楚整个设计的架构之前，一直没有动手写太多实
际的code，更多的时候是用伪码来描述验证自己的设计思想。
花了三天的时间，在一条设计道路上不断地思考，尝试，最终发现并不太可行，于是改换另一个思路继
续进行设计，经过一天时间的设计，发现这个思路也存在一定的缺陷，及至今天，才算是基本确定下来整
体设计的框架。
如果自己这一次还是在设计阶段浅尝之后就开始实际动手coding，恐怕就未必能够及时地意识到设计中
存在的不足了。很多时候，虽然在实际编码的过程中我们能够体会到设计中存在一些缺陷，但是身陷于
细节实现其中，大脑往往被"快点搞定它"的想法所充斥，已经无暇再回到比较高的角度来思考整
个架构的合理性了，这种情况下，往往要待到编码到一个原有的设计缺陷已经无法忍受的状态下，才
会明确清晰地意识到有必要重新考虑设计层面的变化了。
但是到了这种时候，也往往意味着前面大量的实现工作要被推翻重来，不啻为一种浪费。
而在设计阶段，作得细致一些，尽量不要让自己陷入实现的细节中纠缠，即使在仅凭思考和抽象已经不易
把握系统复杂度的时候，也不要轻易诉诸实现，而是借助于流程图，伪码这样的抽象层次较高的手段来协
助自己建立起对系统的具体理解，则有助于以一种有序的方式把握整体的设计了。
设计工作往往是抽象的，不易把握的，甚至是有些痛苦的，因为你往往要从一个空白的起点开始通过抽
象，组合，等等手段构建出一个假想的符合要求的目标架构，这种不够厚实，欠乏实物支撑的感觉经常会
让一个设计经验不是很丰富的开发人员在设计阶段萌生出逃避设计，尽早切入具体coding的想法。
而相比之下，实现工作则具体得多，也易把握得多，也更容易带来快速成就感，所以开发人员可能更容
易倾心于一个具体模块的实现。 这也是诱使我在前面的开发过程中在设计还未足够明晰的情况下就过早
介入具体实现的主要原因。
--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
Kenny Yuan
补充一下哈：可能有人会争辩说：如果不写些代码进行实验或者启发，就完不成好的设计。其实这一条只能说明设计者经验的不足，或者方法上不善于总结：不知道自己过去是如何成功、如何失败的。
至于Agile，应该是另外一个model（依我的个人理解）
我一直认为，重新设计一个有过经验的东西（包括重构和重生）和做一个未知的新东西是有很大区别的。前者适用于文中的原则。
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/
li li
细节实现其中，大脑往往被"快点搞定它"的想法所充斥，已经无暇再回到比较高的角度来思考整
个架构的合理性了
Rui
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
虽然是笑话，但对设计者也应该有些启示吧
博士和小工的区别
据说这是真实的笑话，搏君一笑,看看什么叫资源浪费
话说联合利华新换了一批自动香皂包装机以后，经常出现香皂盒子是空的没有香皂的情况，而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不，一个由自动化，机械，机电一体化等专业的博士组成的Solution队伍来解决这个问题，没多久他们在装配线的头上开发了全自动的X光透射检查线，透射检查所有的装配线尽头等待装箱的香皂盒，如果有空的就用机械臂取走。
不巧，中国一乡镇企业生产香皂也遇到类似问题，老板吩咐线上小工务必想出对策决之，小工拿了一个电风扇放在装配线的头上，对着最后的成品吹之，空盒子被吹走,问题解决之.
pongba
这句话对我印象最深刻，尽管它很抽象，但高层的指导原则几乎总是抽象的。
架构是个很难的领域，优秀的程序员一抓一把，优秀的架构师凤毛麟角。我也有打算好好学习实践一下这个领域:)
pongba
话说联合利华新换了一批自动香皂包装机以后，经常出现香皂盒子是空的没有香皂的情况，而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不，一个由自动化，机械，机电一体化等专业的博士组成的Solution队伍来解决这个问题，没多久他们在装配线的头上开发了全自动的X光透射检查线，透射检查所有的装配线尽头等待装箱的香皂盒，如果有空的就用机械臂取走。
不巧，中国一乡镇企业生产香皂也遇到类似问题，老板吩咐线上小工务必想出对策决之，小工拿了一个电风扇放在装配线的头上，对着最后的成品吹之，空盒子被吹走,问题解决之.
这个我也听过，印象很深刻，这次你贴出来之后我又想，从机器学习的角度来看，这个小工的 feature selection 做得非常棒，因为这本质上是一个分类问题，只要摸到那个对于区分最关键的 feature 就事半功倍了，而小工 select 出来的这个 "重量" 就是一个最佳 feature 。
Du Lei
arena
很想从比较高的角度去思考整个系统的实现，但往往是抽象能力不够，对所涉及的方方面面知识还没融汇贯通，这样情形下，觉得还是coding实现一个简陋
的demo有助于思考
pongba
一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候，如果脑子里有一个与问题场景有某些相似性的既有方案，就会抑制不住地思维被该方案占满，很难实现fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法，为此也在阅读思维/认知科学方面的书，有一些heuristics能够有一定的作用，但是每每还是发现会思维落入盲点 :D
但另一方面，没有知识又真的很难思考。很多时候方案难以完全逆向导出，而是通过联想发现某个既有知识能够被用来解决手头问题的。
我想最终的方案肯定是critical的接受知识，critical的思考。具体的思维方法还在不断反思中..
樊帆
工人日常所做的工作导致了他的思考模式必然是现实、低级的，但在检查空盒的方面却发挥了实效。
而专家因为工作原因，思考的思路必定是专业考究的，但却忽略了小技巧的现实效用。
因此我一直以来认为好的SA必定是Programmer出生，而且也必定是优秀的，so，要做好SA，先做好coding，当然这里的coding是广义的。毕竟望远镜和显微镜是有差异的，必定要身处其中才能有深刻体会的。
Yi Yang
wanng fenng
不但出现盒子是空的情况，还会出现两块香皂挤在一个盒子里边的情况（两块香皂都挤扁了）；同时，流水线上拥挤了很多的盒子，即两个（或以上）盒子可能会齐头并进到达装配线的出口。
说到生产线，呵呵，有一个笑话是关于化繁为简的（虽然不一定真实）
虽然是笑话，但对设计者也应该有些启示吧
博士和小工的区别
据说这是真实的笑话，搏君一笑,看看什么叫资源浪费
话说联合利华新换了一批自动香皂包装机以后，经常出现香皂盒子是空的没有香皂的情况，而在装配线一头用人工检查因为效率问题不太可能而且不保险。这不，一个由自动化，机械，机电一体化等专业的博士组成的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
工人日常所做的工作导致了他的思考模式必然是现实、低级的，但在检查空盒的方面却发挥了实效。
而专家因为工作原因，思考的思路必定是专业考究的，但却忽略了小技巧的现实效用。
你说的这个正是"心中有把锤子，所有东西看上去都是钉子"的扩展版啊 :-)
pongba
一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候，如果脑子里有一个与问题场景有某些相似性的既有方案，就会抑制不住地思维被该方案占满，很难实现fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法，为此也在阅读思维/认知科学方面的书，有一些heuristics能够有一定的作用，但是每每还是发现会思维落入盲点 :D
wanng fenng
越是学历高，考虑问题的时候越容易划地自限。所谓拿这个锤子看见谁都像个钉子。
一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候，如果脑子里有一个与问题场景有某些相似性的既有方案，就会抑制不住地思维被该方案占满，很难实现fresh的思考。
Du Lei
我们都很清楚重新发明轮子的问题。但是往往重新把轮子发明一遍才能够真正理解轮子设计的方方面面，才有可能接触里面隐含的很多思想和思维方式。
pongba
重量的确是一个最佳feature，但相应的应该有能识别这个feature的最简模式，如果专家们知道从重量来分辨肥皂盒，也许他们会整一个电子秤放在装配线上，然后继续使用机械臂取走那些未能达到一定重量的盒子。而小工也许还不一定拿风扇吹哈，把装配线弄斜一点就行了。
恩恩，没错。其实Problem Solving的思维方法真是一个很复杂的学科。温伯格那本《你的灯亮着吗？》其实只是提供了一个不错的例子和几个在个别问题上有意义的heuristics，离真正的方法论还有很远。我一直也没看到这方面写得很好的方法论，《六顶思考帽》又显得宽泛了，泛泛而谈，没有让人一看有如心头明镜的感觉:(
樊帆
毕竟要站在巨人的肩膀上做事，当然对任何事情存疑是值得推崇的，不过也要注意"量"，不过量即可，为了追究根源，会浪费很多精力和时间在次要的问题上。
我恰恰觉得"你的灯亮着吗？"就是要告诉我们注意深刻反思自己的立场和当前所处的"地方"，走过了就倒回来几步，走慢就加快脚步。
pongba
这又让我想到另外一个问题，Google和Wiki上找到的往往是现成的解决问题的手段。这时候面临的问题其实不是Google的知识是否限制了我们的"思考"，而是长期以来现成的解决方案，不去自己尝试解决问题是否限制了我们的"成长"。
我也有此感觉，我们很多时候评估一个方案的时候并不是根据"这个方案理论上已经无法再好"了来评价的，而是根据：
1) 这个方案能够满足我现在的要求，即便有缺点也并非不可忍受。
2) 我想不出更好的方案了。
横跨多个领域的牛人，诺奖得主 Herbert Simon 曾经对 1) 这个标准起名叫 Satisficing （"satisfy" and "suffice"）。这个主观评价标准妨碍了人们进一步追求更好的，更符合手头问题的方案。有时候旁边拿来一个方案虽然不能完美契合，但是扭吧扭吧也就用了，看上去没问题（具体有多大问题，这个又涉及到个人对问题的洞察力了），在设计模式里面这样生搬硬套的例子应该是不少的，我一直觉得设计模式至今的讲授方式是个大问题，应该从问题的剖面出发，以问题解决的思维剥茧抽丝来介绍，最后提出的模式只是思考的结果，而不应该是"锤子"。
昨天在考虑论坛的信噪比解决方案的时候我自己也犯了 satisficing 和 confirming-bias 的问题，因为一开始 assume 没有妥善的解决办法来在当前论坛里解决噪音问题了（这个又是建立在之前对"首贴审核"功能的负面映像之上），所以后来一直都在集中考虑如何把 alternative 的方案完善，走了很远发现初始的步骤就没有考虑周全。之前对"首贴审核"功能的负面映像是建立在没有首页醒目提示和没有成员审核的前提下的，结果在我脑袋里面笼统地变成了"这个功能不可用"，于是就把这个特性忽略了。False Assumption 是很可怕的。会员权限设置我以前也是用过的，但是没发现有什么用，于是又记成了"这个功能反正没啥用"..
lunar_lty
> > TopLanguagehttp://groups.google.com/group/pongba- 隐藏被引用文字 -
>
> - 显示引用的文字 -
同意你的观点：."关键在于Architeture要善用两种不同的工具(望远镜和显微镜)."
Linker
樊帆
我来咬文嚼字一下，我始终觉得，把望远镜和显微镜比作工具，是不恰当的，我觉得用能力比较合适。差别在于，能力需要锻炼，而工具只需要到店铺买就行了。
就像上面说的，你会画UML图并不代表你就能画好UML图。UML是工具，而画好它所需要具备的素质则是能力。
樊帆
pongba
我相信这种现象不仅是 OO ，任何工具（包括知识）只要足够含糊或足够复杂都有可能变成大锤，用人们常用的词就是屁股决定脑袋了..
我不懂 OO, 我只懂解耦合的思想以及解耦合的具体思路（信息隐藏、封装，接口抽象，多态，etc .. ）。
pongba
在软件设计的过程中，我们经常会面临这样的诱惑： 在工作过程中，突然出现了一个问题如鲠在喉，阻塞住了当前整个的工作进度， 而同时，你立刻能够想到一个快速搞定该问题的方案，这种情形下开发人员，很 容易就会受到快速解决问题的诱惑，快速地给出fix，然后继续推进到后面的内容， 维持那种开发过程中酣畅淋漓的快感。但是在开发过程中，不可避免会经常性地遇 到问题，如果经常性地给出快速的fix，到了一定的阶段，可能就会发现，现有的 系统处于一种补丁落补丁的状态，看上去不舒服，在这个不舒服的基础上作后续 的开发也很难受。如果一定要继续坚持维持这个不够好的设计，也许，最终产品 还是能够开发完成，但是它的扩展性，稳定性，可复用性，可修改性都会大打折扣 。 这种对问题快速给出fix的方式，在产品维护的阶段，尚可运用，当然前提是产 品本身的架构设计得足够好。但是在产品的设计阶段，在早期开发阶段，还使用 这种方式，则可能会带来较大的负面影响。 这样的体验，最近自己就有这一回。 最近一直在设计一个处理语意部分的evaluator，期间也遇到了不少问题。初始 给出的设计在后续的实现环节中发现有一些局限，但是在实现的过程中因为过于关 注进度，也在一定程度上受到持续推进的顺畅感的诱惑，自己并没有停顿下来审视 原先的设计，而是稍作思考，给出一个快速的fix，能够解决当前的需要之后，就 继续进行到后续的开发中。虽然在编码的过程中，已经感觉到有些底层数据结构设计的 实在谈不上舒服，为了解决设计问题，引入coding trick的场景也不只一处，但 是身陷其中，并没有想过站起来，从更高的角度进行思考。及至代码基本编写完毕 ，开始测试，暴露出一些bug，需要进行修改的时候，才更充分地体会到现有的设计 的局限性以及这种局限性给维护和扩展带来的开销。这样束手束脚地调试了差不多 一周的时间，基本功能倒是调通了，但是有些不爽的是，这种调通的感觉完全是建立 在调试经验之上的，刨开调试的经验和fix的一些bug，从流程上和框架上来看，自己 对现有的这个版本实现的品质并没有太大的信心，简单来说，让自己闭上眼想一想， 现在的这个设计，这个实现，在品质上是不是达到了自己的要求，是不是在自己的控制 范围内，还是一件说不太清楚的事情。对于一个工业级的软件产品来说，这种控制感实 在是太虚弱了。考虑了一天，跟老大也沟通了一下，决定对evaluator进行重构。从底 层的数据结构的定义，到基本的流程框架，乃至具体的实现，几乎全部要作一番调整。 短期来看，这种调整会给进度带来一定的影响，但是在项目的初期阶段，对于根基性的 东西，还是值得花费较多的资源作精作细，这样后续的开发才可能有一个良好的基础。 P.S. 这段时间一个比较深的体会就是，当你感觉需要实现的某个模块过于复杂，条理 不是非常清晰，或是需要引入特殊的coding技巧来解决一个问题的时候，往往意味着更高 层次上的设计和架构潜伏着问题，所以这种时候，要控制住埋头实现复杂逻辑，引入trick 快速解决问题的冲动，缓冲一下，站起来，审视一下，是不是可以从更高的层次来简化问 题，给出更好的设计，消除引入特殊trick的必要性。 |
樊帆
wanng fenng
其实倒也不必担心"思考"的问题。
毕竟要站在巨人的肩膀上做事，当然对任何事情存疑是值得推崇的，不过也要注意"量"，不过量即可，为了追究根源，会浪费很多精力和时间在次要的问题上。
我更担心的是创新问题。
最近一直在看量子力学，狄拉克将近80年前出的量子力学圣经中，漂亮的数学架构实在是令人叹为观止，如果他出生在我们这个时代，有google可以找到别的数学家的方案，估计现在还在象我一样，忙着推导别人的理论架构吧，狄拉克方程能否问世实在是问题。现在的知识累积实在太多了，一个人很难穷尽一个分支的所有，什么时候该收集资料，什么时候自起炉灶很难判断的说。
Yi Yang
Rui
模式是起点,不是终点.
工具是为人所用的,不是奴役人的.
我教导手下的SA时,以上几点就是反复强调的.
实际上我在这行业混了十几年的结论就是,CS本身革命性的变化非常少,本质上都是相通的,甚至还有思想回潮(就是十几年前的东西突然流行起来,比如重
构).
On 12月5日, 下午7时43分, pongba <pon...@gmail.com> wrote:
> 2008/12/5 Linker <linker.m....@gmail.com>
Rui
这个很难形诸文字的.你在做出一个良好的设计时,自然会有这种感觉的.其实对于一个优秀的Architecture,这种对于好的架构味道的嗅觉是基
础.
Rui
我觉得一个优秀的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的必要性。*
一首诗
我一直以来主要工作是用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
Rui
无法驳倒时才会接受.国内目前的教育过于注重学习及接受,而少有自己思维.
On 12月5日, 下午8时33分, "wanng fenng" <wanng.fe...@gmail.com> wrote:
> 2008/12/5 樊帆 <fanfan19830...@gmail.com>
>
> > 其实倒也不必担心"思考"的问题。
> > 毕竟要站在巨人的肩膀上做事，当然对任何事情存疑是值得推崇的，不过也要注意"量"，不过量即可，为了追究根源，会浪费很多精力和时间在次要的问题上。
>
> 我更担心的是创新问题。
>
> 最近一直在看量子力学，狄拉克将近80年前出的量子力学圣经中，漂亮的数学架构实在是令人叹为观止，如果他出生在我们这个时代，有google可以找到别的数学 家的方案，估计现在还在象我一样，忙着推导别人的理论架构吧，狄拉克方程能否问世实在是问题。现在的知识累积实在太多了，一个人很难穷尽一个分支的所有，什么时 候该收集资料，什么时候自起炉灶很难判断的说。
Kenny Yuan
许多知识在接受时是这个样子的："同学们，今天我们来讲xxxx，xxxx有四个特性，分别为A、B、C、D；关于xxxx有3个定理，分别为Alpha/Beta/Gamma……好的，下面我们开始做题……"
我认为：如果一个人的思维习惯了这种学习方式，知识很容易会成为负担（我个人认为：在中国上过学的，思维大约都会有一定比例受此影响）
在讲授知识时，应该更多地引入这些样的"起源问题"，比如：
1、定理的提出是为了解决什么问题？
2、如此设计的动机是因为什么？
3、器官进化成这样是为了适应什么？优势在哪？
4、这个keyword为什么会出现？其历史原因（背景）是什么？
5、关于此定律的历史争论是因为什么？各自出于什么目的？
6、历史上的错误（悖论）是怎么出现的？是如何解决的？
7、关于这种原则，人们常见的误解和错误使用是什么样的？
8、这种理论是什么时候出现的，当时的社会/科学背景是什么样的？理论之前和之后，带给世界的变化是什么样的？没有它的时候是如何解决问题的？
……
有时候，我们在看一些趣闻逸事（也可称为8卦）的时候，会突然发现"原来是因为这个原因啊！"，感觉"终于理解了"。为什么会有这种情况？因为我们用错误的（至少不完备的）方式来接受了知识。
话题扯回来，如果对每种已知方案，我们都熟知它的应用场合/长处/短处/关联/限制/隐藏的好处/额外的损失/等等……，就有可能得心应手地使用已知方案，减少它们对更优解的思维干扰（非充分条件）
一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候，如果脑子里有一个与问题场景有某些相似性的既有方案，就会抑制不住地思维被该方案占满，很难实现fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法，为此也在阅读思维/认知科学方面的书，有一些heuristics能够有一定的作用，但是每每还是发现会思维落入盲点 :D
但另一方面，没有知识又真的很难思考。很多时候方案难以完全逆向导出，而是通过联想发现某个既有知识能够被用来解决手头问题的。
我想最终的方案肯定是critical的接受知识，critical的思考。具体的思维方法还在不断反思中..
SpitFire
不是非常清晰，或是需要引入特殊的coding技巧来解决一个问题的时候，往往意味着更高
层次上的设计和架构潜伏着问题，所以这种时候，要控制住埋头实现复杂逻辑，引入trick
快速解决问题的冲动，缓冲一下，站起来，审视一下，是不是可以从更高的层次来简化问
题，给出更好的设计，消除引入特殊trick的必要性。
--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
--
SpitFire
一首诗
如果没有一个起点，如何迈出向终点的第一步？
如果不去学习工具，自然不会被工具奴役，但是否也失去了使用工具的机会？
思想的回潮，是时尚界几年一次注定的轮回，还是因为时移世易，旧的方法有了存在的理由？又或者多年的发展之后，当年的天方夜谭，到现在终于有了实用的价
值？
soker
架构往往承载着很多人的工作量,如何把握统一的节奏,对于项目或者软件的成功至关重要. 架构师就象乐团的指挥家,他一有问题,出来的结果就不是美妙音
乐了.
Rui
我也讲一个吧,也算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
这就是重构的一个意义，那就是不能欠下技术债，要不停的使用重构来使设计和实现能很好的解决当前的问题，欠债越多越久，以后还起来就越困难，成本越高。bob大叔在agile社区的发怒贴主要也是说的这个问题。
uncle bob 这个帖子有意思！呵呵:)
Rui
OO只是一种手段,PP,FP都是替代之一.所以我说OO不是目的.OO只是从问题域到解域的一种办法而已.对于架构师来说,他必然不是纯OO的.
Pattern就是一个良好的起点,各种模式告诉我们如何开始,有如围棋的定式一样.我们从定式开始,但并不是为了把棋下成定式那个样子.
为了不被工具奴役,你需要知道工具的本质,知道他的优点和缺点.
在架构师眼里,技术无优劣之分,只有特定的环境才能判断设计的好坏.
你认为过程式方法过时么?在特定的情况下过程式比OO要有力的多.
思想的回潮,我觉得是由于控制CS走势的,其实只有几个关键的元要素,不管以什么样的技术形式出现,决定性的东西其实只有那么几个...
这个我一直在思考,我想这也是冯诺依曼体系的本质在控制着软件技术的走势.这就好象我们在欧氏几何中,用四至五条公理推导出了一大堆的不同理论一样.
什么是冯诺依曼体系的几大公理.我这几年一直在思考,可惜还没有什么突破性的东西.
Martin Fowler的那本企业架构模式(PEAA),我从一开始就不是从应用的角度去读,而是试图从基础理论的角度去思考,希望能有突破.
xxmplus
2008/12/6 Rui <cao...@gmail.com>:
--
Any complex technology which doesn't come with documentation must be the best
available.
pongba
飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
简言之,就是高速时后掠角增大.低速时后掠角减小.
在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.
苏联人的设计令人崩溃的简单.
内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.
我觉得这个例子很赞。我对它的理解是，美国飞行员在计划一开始就犯了false assumption的错误，先入为主的假定了一定要用自动的，也许是因为他们太"高级工程师"了。Anyway，如果一开始的时候能够做横向的思考，众人头脑风暴，应该很容易侦测出犯下的false assumption错误，因为每个人的视角不一样。
Rui
我这个例子里的苏联设计师,我认为从软件架构师的角度讲,他也必定是一个很牛的架构师,因为他会简化问题.
我有一个观点,就是真正的大牛在讲述自己的工作时,能够用不到100字让一个完全没有了解的人清楚自己的工作的意义.
这其实也是一种抓住本质的能力,也是一种复杂模型简单化的能力.
如果架构师不会简化模型,那下面接着的designer和coder就等着受罪吧...
就象MiG-23团队一样,如果不是架构师给出一个很好的变后掠翼实现架构,那后面的具体设计人员和工艺人员就死去吧(苏联当时的工艺水平和制造水平都
与美国有很大的差距)
Rui
我结合下具体的架构师的工作展开讨论.
其实这种事情,在架构师的工作中也是非常重要的,就是区别真正的需求和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
不但出现盒子是空的情况，还会出现两块香皂挤在一个盒子里边的情况（两块香皂都挤扁了）；同时，流水线上拥挤了很多的盒子，即两个（或以上）盒子可能会齐头并进到达装配线的出口。
一个问题的出现是诸多因素组合作用的结果，多个必要前提合取的结果。改变任何一个或多个前提也许就解决了问题，所以我想这里的信息不足，如果是我的话第一步是考察装配线是具体怎样导致香皂挤在一块的，从源头上试着解决问题。
除此之外还可以打补丁，比如用电风扇吹走空盒子就是打补丁方案，不去解决空盒子产生的根源，而是后期将其去掉。具体到这个问题，如果两块香皂的情况少见的话，直接称出来扔掉就可以了 :D
一首诗
抽象，会更容易一些。我们一直都用C，而且是最基本的C，并不是一个技术问题，而是一个历史问题。
我所参与过的例子，都过于简单或者说粗糙。而市面上大多数的东西都是从OO的角度谈问题的解决方法的，同样对我没有帮助。我不是“必然不是纯OO的”，
我是被迫做纯PP的。
有的时候看各位这样的高手讨论，有一种修炼到了很深的地步，看穿一切迷雾，飞花摘叶皆可伤人的地步。所以有没有兵器对你们来说没有什么区别了。
可是我觉得对小兵来说，手中有没有兵器，区别还是挺大的。
另外，我觉得CS毕竟只是Engineering，和纯智力的公理体系去推演还是有很大不同吧。
就像Knuth说过（大意），他能证明一段程序是正确的，但他不能保证这段程序可以工作啊
一首诗
Kenny Yuan
那种笔后来上市了，用于在野外、沙漠、严寒、水下、高海拔等条件下书写——当然，是用在地球上 :)
Rui
你要做个整型数的快排都要搞出N个类来,怎么也是叠床架屋了.
我的意思是想说,OO也是有其局限性的.PP并非一定就不适合.
你说的CS是Engineering,那当然了.但这不妨碍我们去探究它的本质呀.就象中国古代造个亭子,工匠有很多歌诀.不需要什么公式就能造出又好
看又稳固的亭子.但你用数学和力学去分析一下,就会发现这个Engineering有其很深厚的理论基础的.
所以我也在思考,CS,尤其是软件技术的思想回潮其背后的理论基础是什么.
Kenny Yuan
一篇文章
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
（相信例子后面的理念大家看过后都会明白，所以就保持此邮件的简洁，不再多废话了）
1、米国的最新高科技军用飞机试飞，飞行员在跑道上指示电脑将起落架收起来。结果飞机被摔坏了。
（因为电脑没有限制此指令的使用条件）
2、商务飞行中的客机，在降落时，反推器不起作用。飞机冲出跑道（这个例子不再有趣，因为有人KIA）
（因为设计时，反推器的使用有限制条件，但是因为气候原因，系统错误地认为此时不能使用反推器）
一首诗
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
所以认为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
每个软件在开发前，都会有大量的美好愿景，有大量的迷人功能要实现。
但是如果过多的考虑V2，V3等后续版本中可能会引入的功能，那么显然会造成巨大的额外开发负担，并且会使得构架过分复杂。
但是如果在将来发现要实现某个特性时，需要对构架大动干戈，甚至只是修一个BUG，也有可能涉及到构架的问题，那么显然也是巨大损失。
想要找一个在初期足够简单，又有足够发展潜力的方案，真的是很难。
Rui
我觉得最主要的,是在于认识这个系统的本质.所谓模型的简化,其实就是将模型本质化.如果你保留了系统的本质化的东西,那么即使是简化了,在V2和V3
也不太应该出现颠覆性的东西.
当然了,这对于架构师来说本身就是挑战,架构师工作的魅力也就在于这种不能公式化的工作.
一首诗
只是我的经历来讲，面对的更多的是对日常生活的需求的一种实现。我这些年的工作经验，除hash之外，从未用过任何因算法。
"Business Logic"是最没有逻辑的东西，在面对它的时候，用PP的过程，我总有乏力的感觉。银弹是不存在的。但我手里的工具已经挖不出什
么东西了，我感觉换一件，也许会方便一些。
当然，坦白来说，我从来没有机会用OO的方法做过任何一个正式的软件，也许以后也不会有的。路是自己选的，也没人逼我，也许不应该这么抱怨的
Jian Wang
苏联人选择了一个低成本解决眼前问题的方案。
但是美国人的方案风险也非常大，在过了一段时间之后，可能会发现可变后掠翼这个方案本生就不是最优解。我们不再需要可变了。
那么美国人的前期研究就都浪费了。
当然，如果财大气粗，能够承受损失的的话，浪费一些也不错。
2008/12/6 Rui <cao...@gmail.com>:
Rui
现.所以你的说法准确一些,还是美国人先搞出来的.
这个话题到此为止吧.要不然又被人认为是噪声了.:D
Rui
其它都是有益补充...现在FP流行,但是这只是在CODING方面,对于向上(分析和设计)上,FP暂时还没有发展出自己的方法论来.这一点还不及
PP呢(PP有完整的分析方法论,设计方法论和编码方法论)
至少现在讲分析和设计,仍然只有两种选择,OO或者PP.
Rui
苏联人是在他们自己的条件下找到了最优的办法.
Kenny Yuan
Tinyfool
械和高中物理的范畴，那么多经费就算是乱研究，也早就研究成功了。
小工的故事给我的印象类似，工业上面用浮选（重力浮力，逻辑没啥大区别吧）来做分捡也早就不稀奇，没有电动机的时代就有了。所以我觉得这个故事多半也就
是个都市传说之类的东西。为了讲述think different的思路或者逻辑造出来的故事，虽然看着那么的有鼻子有眼睛。
我给你们讲一个完全真实的，发生在我自己身上的。我毕业第一二年，在一个电子厂做网管。技术部有计算机方面的事情也有机械方面的事情要做。技术部常作的
事情就是设计搭设生产线，我们是摩托罗拉的外包组装厂。生产线其实不是那种全自动的传送带式的流水线，就是工人站在一排，拧螺丝之类的。但是我们要自己
做部件测试仪（不买摩托罗拉自己的原因是他们的太贵，他们研发成本高，一个测试仪至少几十万，我们自己做出来，算上机械和里面嵌入式Pc，最多1万也就
搞定了），每个部件，比如翻盖手机前盖，拧螺丝前后，都要在测试仪上面检查屏幕是否能够输出全部的内容，有没有坏点等等；对于手机主体就是让机器手点一
遍所有的键盘，看看键盘是不是会发出正确的信号等等。
所有的手机其实都大同小异，所以每年我们的测试仪研发都很顺利。直到那一年，手机越来越小，部件之间的连接排线越来越窄，排线接果越来越小，接口的线数
却越来越多了。为了连接可靠，接口往往是带应力，容易连接不容易松开的那种。以前测试仪都用跟手机排线接口配对的接口，现在不行了，接上就很难弄下来，
测试效率下来了，生产效率就下来了（全部部件100%要测试的）；而且更难办的是如果弄下来的时候稍不小心可能会损坏接口，这就造成废品率的狂增。
我们后来采用了极细的弹簧针制作的插头，弹簧针的粗细具体数值我忘了，反正比家里最细的针还细，因为很细，所以很软，我不小心损坏过一个后，折开它，用
显微镜看过，那么细的针居然真的是中空的，里面还有缠绕的弹簧。那种针一根就几十块钱。当时国内没有卖的，好像是从日本进口的。我是学机械的，我想象都
想象不出来这东西是怎么加工的。一般中空的弹簧针的加工工艺肯定是搞不定的这种针，这你放心。为了制作插头，我们自己做有机玻璃块，然后找了一家可以做
精密机加工的军工给我们打孔，那个床子又是十几万美金的东西，当然我们只是租用。然后，特意进口的超细钻头，跟针一样很细，很软，那家军工的工程师拿到
钻头的时候放在手里面看了一眼，居然给搞坏了钻头，幸亏预先就想到这种东西不可能结实，一次就买了5个。那钻头在床子转速没上6万的时候，都不能启用。
所以你知道这个插头有多金贵了吧。可是，你测试仪的台子不可能太精密，居然插头很精密，操作工不可能用显微镜操作。结果做几万个就要换一个插头，成本极
高，要知道组装是利润很低的。（我们那边废品率绝不能高过万分之三，万分之三就意味着白干，废品要赔，一个前盖要赔几十美元，三个就白干，你这下知道一
万个加工费才多少了吧）。
最后，我倒是想出来一个好办法，用柔性电路板来印触点，然后在下面放一个薄海绵电子。手机的排线接口往上一压，就可以接触上了，非常耐用，关键是便宜，
印一筐也就是一个弹簧针插头的价钱。
好，如果故事就这么完了，我也成了一个都市传说制造者。当然没有那么好。插座插头，排线接口，总是一个公一个母的。我设计出来的方法只能解决公的排线接
口，他的触点是外露的。母的，在我离开那家公司之前，仍旧是用弹簧针插头做的。当然制作工艺仍旧是不停的改进，越来越可靠，越来越便宜了。
我是想说，解决问题往往有两个办法，一个恒久远永流传，但是重剑无峰看着那么的白痴。就像美国的自动变翼，博士的复杂生产线筛选技术，弹簧针插头，他们
关注于问题的核心和实质；另一种更注重实际，也许解决不了终极问题，但是现在正好够用，比如带档位的变翼，电风扇吹盒子，我的柔性电路板。我们的传统教
育和生活常识让我们更喜欢后一种，觉得务实，省力快。然而，一快则一慢，省力则距离长。
假设只有无级才能实现1024度旋转，从而百分百逃离导弹的新需求出现了，那么仅为了变速才设计的带档位的变翼可能就要彻底抛弃。假设空盒子问题解决了
以后，新的质量问题是某些盒子颜色印错了，小工的方案似乎就多余了。博士的方案无非是质量传感器，再多个颜色传感器。柔性电路板亦然，如果公司接到的单
子都是公口的，那就算了，一辈子用柔性吧。但是难道来了母口的单子你不接么？再者，现在有些接口的公口前端是没有触点的，触点都在侧面，柔性不也不行了
么。
我说的这些假设也许不会发生。但是我担心的是一种思想，一直事事想走捷径的思想，被传统教育带给我们的。我从小喜欢机械，所以大学报了机械专业（另外的
原因是分不够计科系）。但是大学第一堂机械设计课后，我对机械的兴趣全部都消失了。因为老师告诉我们，我们国家的机械工业主要是模仿设计，就是人家有个
东西我们拆了，然后画图，然后加工出来。老师告诉我们轴的粗细都是靠经验公式，设计余量是1.5倍。齿轮都是模数齿轮，设计的时候按照公式。
你如果看过王小波小说里面描写的数独社会的机械工程师怎么用球墨铸铁做柴油机，你就会发现那不是夸张。我们的机械（这些年有好转，但是可能会更可悲，我
后面会写为什么）为什么看着笨重，形状单一，就是因为构件的尺寸都是经验公式，因为是经验，应力承载都是估算出来的，所以设计余量大，所以笨重，而且不
可靠。
你可能会说，这一暂时的，那时候我们只能这样。没错，但是你知道，浮沙之上不能筑高台。
我毕业前夕，忽如一夜春风来，大学里面开始流行有限元分析，pro-E等等等等。有了有限元多扯淡的形状你都可以设计了，不用经验，你可以用计算机算
了，对吧。跨越式发展达成了吧？错，大错特错。我们学校是石油部的部属院校，机械系的几个老师发明了一个非常牛屄的三牙轮钻头，就是用有限元等计算机手
段设计出来的。结果呢？第一，那个形状是一个完全非常规的曲面，学校和国内钻头产生的数控机床根本做不出来，没有那么多轴向的加工能力。第二，即时买个
牛屄的机床回来，培养出会使用的人也需要很多年。编程可能倒是简单的问题了，数控机床是需要你对机械加工涉及到的工艺和力学问题有丰富知识的，尤其是这
种非常不简单的机床。那么我们伟大的跨越式发展的设计产品怎么办了呢，很简单卖给外国的钻头厂商了。据说是百万美金，可是你知道百万美金，买真正好的钻
头的话，也买不了多少个的。能自己生产，打死也不能卖啊。
我毕业前参观过某重型机械厂，据说国内大型项目的机械构建都是他们生产的，必须大型水电的发电机轴等等。他们所有加工机床几乎都是进口的，西门子的超长
镗床，钻床，1200吨的捷克产的水压机（40年前进口的，直到05-06年，国内才有了更大的国产水压机，江南造船厂的那个水压机，应该比这个小或者
是一样大）。问道他们为什么这些都进口，原因很简单，很多东西有需求，但是国内自己造不出来。歼十的生产厂我们也参观过，他们做军工之外，还做波音的机
尾的组装，他们是很强的单位了，但是自己为什么不做大飞机。当年我问过他们，他们说做不了。现在国家又开始立项大飞机项目了，但是多少光阴已经过去
了。
想起来的事情太多了，逻辑有点混乱了。索性继续说下去，反正是在论坛不是blog。
最近一起程序有篇文章是采访余平六段和他们的计算机围棋Team的故事，他们这次得了第五。第一是用了最新的数学方法，他们最近也开始研究这个领域。这
个故事多么的似曾相识。当年陈志行的手谈称霸计算机围棋比赛的时候，大家是怎么说的，说中国人懂围棋，这个领域只有中国人才能突破。甚至现在前几名都不
是亚洲的，陈志行更是早就不行了。
似曾相识吧？过去UCDOS和WPS最火的时候，我们都说中文操作系统还是要靠中国公司。现在内，我用了10多年的中文Windows了，现在用中文的
Macosx，哪个是中国公司的？有个百度说自己最懂中文，那么我们看看中文分词的核心技术是中国人搞出来的么？哪个算法是？我看了这个领域的很多
Pager了，无非是把老外的成熟经验拿来修修补补，巨大开创性的有来自中国人的么？现在，有很多论断说美国经济不行了，中国要领导全球经济了之类；或
者说中国是这次大危机唯一的背风港，我也觉得似曾相识。说起来美国次贷之前，我就更早的担心中国经济了。人家美国次贷不靠谱，中国的贷款买房就靠谱么？
首付20万-40万，多少年轻人是一己之力拿出来的，多少人是一次性把自己父母一辈子的积蓄扔出去了？多少人考虑过20-30年的还款期，如果自己失业
个一年半载（经济要是不好的话，这可不稀奇），钱还不上，银行可能收房（政府有政策不让收一房，这我知道，但是经济真得危机的时候，这政策相当于多少亿
钱直接水飘，政府官员出台政策的时候算过么？这么大利益，会有人不杀人防火的收房么？）
又开始跑题了，回到软件。我做的所有东西，设计有所保留，不仔细想清楚的，使用维护中都带来无数的问题，尤其是难以修改，系统跑起来以后，任何修改都要
考虑不改变用户原来的习惯。
所以，我倾向于把问题想清楚些，至少逻辑要相同，少用一些特别花巧的技巧，尤其是跟某些会变的因素有关的，比如你假定用户不会超过200个，你就用个8
位来做Id，万一超了你怎么办？
supern lee
Jun Yang
本来写这篇文章的初衷只是作为一篇个人最近一段时间工作的感想总结，没想到在pongba这里有这么多讨论，涉及这么多内容，让我长
了不少见识。
看了一下大家的回帖，也有一些想法，发上来交流一下。
1. "我一直认为，重新设计一个有过经验的东西（包括重构和重生）和做一个未知的新
东西是有很大区别的。前者适用于文中的原则。"
Kenny 所说的重新设计一个有经验的东西和做一个未知的新东西是有很大区别的， 我比较好奇，
能不能谈得具体一些啊？
2."就我的经验,新手SA/Architecture最容易犯的错误,就是只见树木不见森林.Architecture要既有望远镜,又有显微镜,并且
要知道什么时候该用望远镜,什么时候该用显微镜.
我同意原贴中关于快速prototyping,pseudocode来做概念验证,但就我感觉来说,新的Architecture更容易犯的,是这种
只见树木不见森林的错."
Rui的眼光很毒啊，我正是刚作Architect相关的工作没多长时间，你所说的新上路的Architect会犯的错误，我要么已经犯过，要么正在
犯，要么可能会犯。。。
以前自己主要是作一些比较具体的开发工作，即便曾经独立负责过项目，也是在已有的大的产品框架里作局部的拓展和增强，并没有太多
架构方面的积累。也是最近，才有机会从头开始设计一个产品，会有一些相关的感受。
如你所说，Architect既要有望远镜，也要有显微镜，但最难的恰恰是知道在什么时候应该用哪种工具来更好的完成任务。脱离了显
微镜，可能会因为对重要细节feature的遗漏而导致给出的架构，依赖的模型中存在重大的潜在风险，而不能适时地使用望远镜，又可能
会因为过于纠缠于细节而疏漏了对宏观架构的把握，而且对于一个技术挑战性较高的项目，过分关注细节还会增加因为追求细节完美以至
于项目流产，延期的风险。对宏观设计与微观洞察这二者的平衡和把握，对于我这种刚上路的作架构的人不是件容易的事情，我现在也没
有什么好的办法，目前还是只能靠多思考，多总结，每隔一定的阶段就跳出现有手上的工作来换一个层次审视自己的工作状况来应对。不
知道Rui有没有什么好的经验可以分享一下?
3."一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候，如果脑子里有一个与问题场景有某些相似性的既有方案，就会抑制不住地思维被该方案占满，很难实现fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法，为此也在阅读思维/认知科学方面的书，有一些heuristics能够有一定的作用，但是每每还是发现会思维落入盲点"
pongba说的，我也很有同感，一方面，需要不断的去拓展积累新的知识，让自己有足够深，足够广的背景，但另一方面，在解决问题的
时候，还要避免落入自己已有的知识体系的俗套，要有突破，创新，这实在不是件容易的事情。从人类进化的历程来看，尽可
能复用已有的经验积累是确保获得生存机会的成本最小的一种方案，这种选择方式也许已经扎根在我们的基因深处了。但已有的经验又不
是放之四海而兼准的。所以总需要有人去突破已有的知识体系，去创新，变革，提出更好的解决问题的方案。
而真正能够在掌握了足够多的知识的基础上还去破去立的，才是大宗师，这样的人稀矣。
4.
"我们都很清楚重新发明轮子的问题。但是往往重新把轮子发明一遍才能够真正理解轮子设
计的方方面面，才有可能接触里面隐含的很多思想和思维方式。"
Du Lei所说的重复发明轮子的问题，我觉得挺有意思的，一方面，在工作中，我们会尽可能避免重复发明轮子，因为从短期或是中期的
效益回报上来说，重复发明轮子是会有一定的损耗的，尤其是对于商业化运作的公司，但是从长期（特别是个人的长期发展）
来看，适当地作一些重新发明轮子的工作会大大增强对轮子的内部机理的把握，有助于发明出更好的轮子，以及发明别的轮子。个人观
点，想去创造一项事物的人，可以去多尝试去发明一些已经存在的轮子，而执著于资源整合的人，则不用考虑作这种事情了。
5. "软件设计不同于建筑的重要一点是,设计和实现无法高效分离.
如果做设计的人不去实现,那么设计必然不够"实现友好". "
Linker所说的"高效"能不能阐释的再具体一些呢？
个人感觉，有不少软件系统，在一定程度上是可以作到设计和实现的分离的，大量的外包软件项目就是例子。 当然， 对于高技术含量的
项目，也许设计和实现的分离会受到一些限制。也想听听大家对这个问题的观点。
6. " 我相信这种现象不仅是 OO
，任何工具（包括知识）只要足够含糊或足够复杂都有可能变成大锤，用人们常用的词就是屁股决定脑袋了..
我不懂 OO, 我只懂解耦合的思想以及解耦合的具体思路（信息隐藏、封装，接口抽象，多态，etc .. ）。 "
pongba说的，让我想起在哪看到的一种说法，说的是关于一个人学东西，可能会经历的境界变换，这种说法里提到在一开始看山是山，
看水是水，及至到了一定的阶段， 又会看山不是山，看水不是水，再到一定阶段，又回归到山是山，水是水的状态了。
7.
"我觉得杨军如果可以把实际的开发代码拿出来按时间顺序先后解剖分析，或许可以给
我们大家的思考带来不错的锻炼呢。不过如果因为商业机密而不便拿出也没办法。"
如樊帆所说，确实因为商业机密的问题，是不方便把我在公司作的东西的细节拿出来讨论的。不过我想在这里的大多数同好，背景经验也
都有所不同，如果讨论的东西过于关注细节的话，会增加讨论和理解的障碍。也许保持一个适当的抽象程度，站在略高一点的层次讨论起
来更有利于交流呢。
8. "嗯.这是个实际问题.
我觉得最主要的,是在于认识这个系统的本质.所谓模型的简化,其实就是将模型本质化.如果你保留了系统的本质化的东西,那么即使是简化了,在V2和V3
也不太应该出现颠覆性的东西.
当然了,这对于架构师来说本身就是挑战,架构师工作的魅力也就在于这种不能公式化的工作. "
对这段话很是心有戚戚啊,呵呵
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
Kenny Yuan
给你最后的一段话提供一个故事（同样，不保证真实性）：
早期的商务飞行都是使用比较小的飞机，据说当时的定票系统对于座位的编号使用的是8位的整数进行存储。直到有一天出现了波音xxx飞机……
（故事往往是给人启示的，而且是仁者见仁智者见智。但故事带给人的冲击力和影响力，往往是比说理更有效的。可能是因为我们都进化出了这样的心理机制吧，所以用例子更能触动我们的思想。想想看：人类目睹别的个体的活生生的教训应该有上百万年了，但人类发展出完善的形式/符号逻辑才有多少个年头？）
所以，我倾向于把问题想清楚些，至少逻辑要相同，少用一些特别花巧的技巧，尤其是跟某些会变的因素有关的，比如你假定用户不会超过200个，你就用个8
位来做Id，万一超了你怎么办？
Jun Yang
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
Kenny Yuan
1、前面写过的两个例子：
例A：飞机降落时反推器无法动作，因为检测起落架的机构误动作；
例B：跑道上的飞机能够收起起落架。
（新系统中所做的"防御"往往会过多，没有融合到正常逻辑中去。同时这种防御有时也会缺失。这些问题，可以解释为经验不足）
2、某个发展了十几年的，在行业内领先，年收最高达几十亿美元的软件系统，其内部结构却非常混乱。各种fix所占的代码比例甚至超过正常的业务逻辑（最高可达几倍）。但这个系统的设计却是同时代的产品中最好的，其设计也曾被评论为优秀的。
（设计的前瞻性不足，没有提供足够的弹性来容纳这些fix，所以多数fix不得不硬编码。如果重新设计这个系统，这些fix就能够转化成经验让新系统更简洁更有弹性）
拥有丰富的行业经验、足够设计出良好架构的人，往往不是软件结构设计师，而这个层面上的交流是一定会出问题的（Murphy's Law）。设计师学习的过程也就是让系统在碰壁中完善的过程。
以上仅为不完善的说明和不完备的说理:)
1. "我一直认为，重新设计一个有过经验的东西（包括重构和重生）和做一个未知的新
东西是有很大区别的。前者适用于文中的原则。"
Kenny 所说的重新设计一个有经验的东西和做一个未知的新东西是有很大区别的， 我比较好奇，
能不能谈得具体一些啊？
Kenny Yuan
商界有个传统，想要用数据说服别人（customer/boss），都习惯在presentation中放图形。而不仅仅是使用才发明了几千年的文字。为什么图形更有冲击力呢？
Hongzhang Liu
2008/12/5 Rui <cao...@gmail.com>:
> 嗯.既然提到这个空盒子的.
> 我也讲一个吧,也算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
有趣的解释:D
我也有个问题：美国人是没想到手动方案还是想到了但还是决定做无级变速的呢？
Hongzhang Liu
2008/12/5 一首诗 <newp...@gmail.com>:
pongba
以下拷贝粘贴我之前在一个主题里面贴过的这段故事：
看到这里我忽然想起老爸给我讲过他当年的一个事情，也有点这个意味，事后看上去简单（心理学里面著名的"事后偏见"效应），但事前要想出来却需要 out-of-the-box 的思维，是这样的：
老爸是搞电气的，（经过简化）当时的问题就是需要将三个半导体并联到一个电路中，并需要确保三条并联支路的电阻一模一样。而问题在于半导体有一个啥啥特性（我不是学这个的，不记得名词了），这个特性使得无法找到电阻精确相等的三个半导体。所以就需要弥补电阻误差。到这里很多人都想到可以在每个支路上添加补充电阻（那个专业的名词我不记得），可在当时的具体问题场景下，添加补充电阻的问题很大，因为电路的功率非常非常大，所以补充电阻的体积也会非常巨大，发热量也大（也许还有其他因素总之就是这个方案在当时的问题场景中行不通）。当时一干工程师就没辙了，因为传统上遇到这个问题都是这么解决的。然后老爸想了很久终于想到一个法子，考虑到那个电路的铺设需要很长很长的电缆，而电缆本身是有电阻的，所以不妨利用电缆本身的电阻来平衡三条之路的电阻，结果一个毫不费力的方案就这么诞生了，问题就这么解决了。
我给你们讲一个完全真实的，发生在我自己身上的。我毕业第一二年，在一个电子厂做网管。技术部有计算机方面的事情也有机械方面的事情要做。技术部常作的
事情就是设计搭设生产线，我们是摩托罗拉的外包组装厂。生产线其实不是那种全自动的传送带式的流水线，就是工人站在一排，拧螺丝之类的。但是我们要自己
做部件测试仪（不买摩托罗拉自己的原因是他们的太贵，他们研发成本高，一个测
Hongzhang Liu
其实苏联人的方案，拿到软件行业来说，也就一个quick and dirty的手段而已，而这正是这个主题所批判的……
2008/12/6 pongba <pon...@gmail.com>:
张慧聪
蒙面骑士
Jun Yang
现有给出的设计看上去很简洁，在简洁的背后已经蕴含了对以后可能有的复杂变化的包容和支撑。举个不太恰当的
例子，冯诺伊曼理论，在概念上描述起来如此简单，却足以作为基石支撑起计算机诞生以来所有的体系结构方面的研究。
换句话说，就是"深入浅出"，能够把问题想得足够深入，才能够给出足够简洁的设计。
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
莫华枫
嗯.既然提到这个空盒子的.
我也讲一个吧,也算Problem solving话题之一好喽.
飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
简言之,就是高速时后掠角增大.低速时后掠角减小.
在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.
苏联人的设计令人崩溃的简单.
内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.
在早期太空竞赛的时候，美国人和苏联人都需要能够在太空失重环境下使用的笔。美国人花了几百万美金，终于开发出可以在零重力底下使用的圆珠笔。苏联人呢？他们用铅笔。:D
我要说的是，尽管这个故事基本上是真的。但是，如果想从中推断出美国人如何把事情高复杂，苏联人如何把事情高简单，以至于说明设计的思路好与坏，那就错了。
如果从另一面看一下这个故事，事情或许有另一种解释。为什么美国人没有用铅笔？美国人天生喜欢把问题想复杂？他们不知道铅笔可以在失重情况下使用？这有些太夸张了。我们再看一下，国际空间站上用的是什么笔？现在，根本不可能在空间飞行其中看到铅笔。包括俄国人本身的飞行器。因为那是常危险的东西。铅笔需要削的，铅笔屑是导电的，在失重情况下会飞得到处都是，而且那儿都能进，对电器设备是极大的威胁。人吸入铅笔屑，也不是见好事。即使不削，铅笔也会在使用的过程中产生碎屑。当时苏联人使用铅笔，并不是铅笔好用，而是迫不得已，或者权宜之计。为了赶紧度。从长远来看，美国人的路线才是正道。事实上，这种权宜之计在苏联航天史上比比皆是。第一位太空行走的列昂诺夫就差点因为这些权宜之计而永远留在太空。
再来看看MiG-23。MiG－23的分级变后掠翼的确简单很多。但是，它是否能够达到无极变后掠翼的效果呢？差得很远。请注意，这和肥皂盒案例有根本性的差异。小工的方法达到了那些复杂方案相同的效果。但MiG－23不同，MiG-23差不多可以算MiG最失败的作品。尽管宣传上拥有很多光环，但是其实际战果和服役记录，无论在两伊战争还是中东战争中，都是最差的，甚至还不如老旧的MiG－21。很显然，在天上，战斗机驾驶员已经有足够多的操心事，如果还要他们看着速度表，心算着机翼的档位，不断地把手从油门杆上移开，操作机翼，那么这还能得到什么好的效果？事实上，MiG－23差不多是一架固定翼飞机。在实际飞行中，特别是在空战中很少变换机翼。却背负着变后掠翼的重量。更糟糕的是，这种走捷径的方法迷惑了苏联（领导）人，以至至今也没有真正意义上的变后掠翼战斗机。
反观美国人，傻兮兮地硬啃自动化的无极变后掠翼，结果F－111A流产。但钱没有白扔，从F－111A的废墟上重生的F－111B成为了最成功的远程攻击战斗机。而在此基础上发展而来的F－14，则是一代名猫，甚至在演习中打败了f-15。粉丝遍及天下。去年方才光荣退役。
我抬这些扛的意思是说，这些故事有的能够说明问题，但更多的并未表达出深层的意义，以至人们错误地理解。的确，简单是工程中最重要的原则。但是，简单不是绝对的。在不同的时候，有着完全不同的效果。事物都有两面，简单也是一样，在拥有很好的作用的同时，也会带来某些副作用。我们只能辩证地分析问题，作设计。有时，简单同时却又是复杂的。举个例子，有一种喷气发动机，叫超音速冲压发动机。结构非常简单，就是一个一头大一头小的通道。简单吧，但是其中的气流是极端复杂的，少有差池，火都点不着。简单当中也蕴含着复杂的东西。比如python。语言是够简单的，但是设计简单的语言，可能比复杂的语言更困难。
所以说，简单不是绝对的。简单必须是恰当的简单。当我们制定一个简单的方案的时候，最好从反面思考一下，这是否是一个有效的简单。
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
Rui
我举这个例子,主要是说明,对于架构师来说,需要有效的进行模型的简化,否则对下一层的设计和实现会有巨大的压力和不好的影响.
但当然大家不能走到反面去...如果简化到影响了可扩展性和功能的有效性,那当然就完蛋了.
老莫是个真正的军迷,所以对MiG-23的设计有更好的意见,我那个是半瓶醋,只是用来说明架构师的责任的.呵呵.
On 12月6日, 下午8时59分, "莫华枫" <longshank...@gmail.com> wrote:
> 2008/12/5 Rui <cao...@gmail.com>
>
> > 嗯.既然提到这个空盒子的.
> > 我也讲一个吧,也算Problem solving话题之一好喽.
>
> > 飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
> > 那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
> > 简言之,就是高速时后掠角增大.低速时后掠角减小.
>
> > 在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
> > 美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
> > 系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.
>
> > 苏联人的设计令人崩溃的简单.
> > 内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
> > 这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.
>
> 这类故事还有很多。我这里还有一个更出名的：
> 在早期太空竞赛的时候，美国人和苏联人都需要能够在太空失重环境下使用的笔。美国人花了几百万美金，终于开发出可以在零重力底下使用的圆珠笔。苏联人呢？他们用 铅笔。:D
> 我要说的是，尽管这个故事基本上是真的。但是，如果想从中推断出美国人如何把事情高复杂，苏联人如何把事情高简单，以至于说明设计的思路好与坏，那就错了。
> 如果从另一面看一下这个故事，事情或许有另一种解释。为什么美国人没有用铅笔？美国人天生喜欢把问题想复杂？他们不知道铅笔可以在失重情况下使用？这有些太夸张 了。我们再看一下，国际空间站上用的是什么笔？现在，根本不可能在空间飞行其中看到铅笔。包括俄国人本身的飞行器。因为那是常危险的东西。铅笔需要削的，铅笔屑 是导电的，在失重情况下会飞得到处都是，而且那儿都能进，对电器设备是极大的威胁。人吸入铅笔屑，也不是见好事。即使不削，铅笔也会在使用的过程中产生碎屑。当 时苏联人使用铅笔，并不是铅笔好用，而是迫不得已，或者权宜之计。为了赶紧度。从长远来看，美国人的路线才是正道。事实上，这种权宜之计在苏联航天史上比比皆是 。第一位太空行走的列昂诺夫就差点因为这些权宜之计而永远留在太空。
> 再来看看MiG-23。MiG－23的分级变后掠翼的确简单很多。但是，它是否能够达到无极变后掠翼的效果呢？差得很远。请注意，这和肥皂盒案例有根本性的差异 。小工的方法达到了那些复杂方案相同的效果。但MiG－23不同，MiG-23差不多可以算MiG最失败的作品。尽管宣传上拥有很多光环，但是其实际战果和服役 记录，无论在两伊战争还是中东战争中，都是最差的，甚至还不如老旧的MiG－21。很显然，在天上，战斗机驾驶员已经有足够多的操心事，如果还要他们看着速度表 ，心算着机翼的档位，不断地把手从油门杆上移开，操作机翼，那么这还能得到什么好的效果？事实上，MiG－23差不多是一架固定翼飞机。在实际飞行中，特别是在 空战中很少变换机翼。却背负着变后掠翼的重量。更糟糕的是，这种走捷径的方法迷惑了苏联（领导）人，以至至今也没有真正意义上的变后掠翼战斗机。
> 反观美国人，傻兮兮地硬啃自动化的无极变后掠翼，结果F－111A流产。但钱没有白扔，从F－111A的废墟上重生的F－111B成为了最成功的远程攻击战斗机 。而在此基础上发展而来的F－14，则是一代名猫，甚至在演习中打败了f-15。粉丝遍及天下。去年方才光荣退役。
> 我抬这些扛的意思是说，这些故事有的能够说明问题，但更多的并未表达出深层的意义，以至人们错误地理解。的确，简单是工程中最重要的原则。但是，简单不是绝对的 。在不同的时候，有着完全不同的效果。事物都有两面，简单也是一样，在拥有很好的作用的同时，也会带来某些副作用。我们只能辩证地分析问题，作设计。有时，简单 同时却又是复杂的。举个例子，有一种喷气发动机，叫超音速冲压发动机。结构非常简单，就是一个一头大一头小的通道。简单吧，但是其中的气流是极端复杂的，少有差 池，火都点不着。简单当中也蕴含着复杂的东西。比如python。语言是够简单的，但是设计简单的语言，可能比复杂的语言更困难。
> 所以说，简单不是绝对的。简单必须是恰当的简单。当我们制定一个简单的方案的时候，最好从反面思考一下，这是否是一个有效的简单。
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
张慧聪
我抬这些扛的意思是说，这些故事有的能够说明问题，但更多的并未表达出深层的意义，以至人们错误地理解。
Jay True
这类故事还有很多。我这里还有一个更出名的：
在早期太空竞赛的时候，美国人和苏联人都需要能够在太空失重环境下使用的笔。美国人花了几百万美金，终于开发出可以在零重力底下使用的圆珠笔。苏联人呢？他们用铅笔。:D
pongba
如果从另一面看一下这个故事，事情或许有另一种解释。为什么美国人没有用铅笔？美国人天生喜欢把问题想复杂？他们不知道铅笔可以在失重情况下使用？这有些太夸张了。我们再看一下，国际空间站上用的是什么笔？现在，根本不可能在空间飞行其中看到铅笔。包括俄国人本身的飞行器。因为那是常危险的东西。铅笔需要削的，铅笔屑是导电的，在失重情况下会飞得到处都是，而且那儿都能进，对电器设备是极大的威胁。人吸入铅笔屑，也不是见好事。即使不削，铅笔也会在使用的过程中产生碎屑。当时苏联人使用铅笔，并不是铅笔好用，而是迫不得已，或者权宜之计。为了赶紧度。从长远来看，美国人的路线才是正道。事实上，这种权宜之计在苏联航天史上比比皆是。第一位太空行走的列昂诺夫就差点因为这些权宜之计而永远留在太空。
再来看看MiG-23。MiG－23的分级变后掠翼的确简单很多。但是，它是否能够达到无极变后掠翼的效果呢？差得很远。请注意，这和肥皂盒案例有根本性的差异。小工的方法达到了那些复杂方案相同的效果。但MiG－23不同，MiG-23差不多可以算MiG最失败的作品。尽管宣传上拥有很多光环，但是其实际战果和服役记录，无论在两伊战争还是中东战争中，都是最差的，甚至还不如老旧的MiG－21。很显然，在天上，战斗机驾驶员已经有足够多的操心事，如果还要他们看着速度表，心算着机翼的档位，不断地把手从油门杆上移开，操作机翼，那么这还能得到什么好的效果？事实上，MiG－23差不多是一架固定翼飞机。在实际飞行中，特别是在空战中很少变换机翼。却背负着变后掠翼的重量。更糟糕的是，这种走捷径的方法迷惑了苏联（领导）人，以至至今也没有真正意义上的变后掠翼战斗机。
反观美国人，傻兮兮地硬啃自动化的无极变后掠翼，结果F－111A流产。但钱没有白扔，从F－111A的废墟上重生的F－111B成为了最成功的远程攻击战斗机。而在此基础上发展而来的F－14，则是一代名猫，甚至在演习中打败了f-15。粉丝遍及天下。去年方才光荣退役。
经典经典！:D 我虽不是军迷，但是这段看得我心向往之:P
valpa
经验越丰富的人思维也越狭窄！
On 12月5日, 下午6时09分, pongba <pon...@gmail.com> wrote:
> 2008/12/5 Du Lei <dule...@gmail.com>
>
> > 越是学历高，考虑问题的时候越容易划地自限。所谓拿这个锤子看见谁都像个钉子。
>
> 一点没错。我是越来越发现知识本身对思维的阻塞。想问题的时候，如果脑子里有一个与问题场景有某些相似性的既有方案，就会抑制不住地思维被该方案占满，很难实现-fresh的思考。可以说是既有知识block了思维。我很想弄明白如何能够避免这个办法，为此也在阅读思维/认知科学方面的书，有一些heuristics能-够有一定的作用，但是每每还是发现会思维落入盲点
> :D
莫华枫
第一个案例我以前说过。我们一个查询网站，用asp.net做的，全本的C＃。倒霉的我，接收了。做网页是容易，贴贴控件，很快就好。这是简单。但是，那天当我在杭州湾边上的一家学校里实施的时候，用户要求一个maque跑得快些。结果，我不得不跑过半个校园，从同事那里取来笔记本，把500改成200，重新编译，然后拷贝到u盘，再拷贝到服务器上。里里外外半个多种头。
第二个案例，是前一个的延续。这个网站需要加功能，我就索性翻倒重来。用js＋jquery做网页，asp.net作为后端，访问数据。所有的查询存放在xml文件中。并且利用sql2005的for xml生成层次化的xml数据，用xquery和xslt将其转换成html片段。结果，实施的时候，用户题出了一些修改意见，包括版面的和查询的。我们都现场改好，最多的一个也就用了不到半小时。当天我根本没有带笔记本，一个u盘什么都搞定。
案例一中，C＃提供了一个构建网站的快速方法，但是在实际的应用中，却带来了更多的复杂性。而案例二中，我动用了不下五种技术手段，对于很多程序员（至少我身边的那些）而言，足够复杂的了。但是，在面对用户变化的需求的时候，却使得问题更加简单。（我们不准用python，否则还要简单）。我那个混合了众多技术手段的方案算是够复杂的，但是这些专用技术的组合却在总体上简化了问题。
valpa
做的复杂的过程本身就是积累，只有在不浮躁的环境下才可以做
在目前社会这个氛围中，推崇简单也许是件好事情，也许不是
On 12月6日, 下午8时59分, "莫华枫" <longshank...@gmail.com> wrote:
> 2008/12/5 Rui <cao...@gmail.com>
>
> > 嗯.既然提到这个空盒子的.
> > 我也讲一个吧,也算Problem solving话题之一好喽.
>
> > 飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
> > 那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
> > 简言之,就是高速时后掠角增大.低速时后掠角减小.
>
> > 在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
> > 美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
> > 系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.
>
> > 苏联人的设计令人崩溃的简单.
> > 内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
> > 这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.
>
> 这类故事还有很多。我这里还有一个更出名的：
> 在早期太空竞赛的时候，美国人和苏联人都需要能够在太空失重环境下使用的笔。美国人花了几百万美金，终于开发出可以在零重力底下使用的圆珠笔。苏联人呢？他们用-铅笔。:D
> 我要说的是，尽管这个故事基本上是真的。但是，如果想从中推断出美国人如何把事情高复杂，苏联人如何把事情高简单，以至于说明设计的思路好与坏，那就错了。
> 如果从另一面看一下这个故事，事情或许有另一种解释。为什么美国人没有用铅笔？美国人天生喜欢把问题想复杂？他们不知道铅笔可以在失重情况下使用？这有些太夸张-了。我们再看一下，国际空间站上用的是什么笔？现在，根本不可能在空间飞行其中看到铅笔。包括俄国人本身的飞行器。因为那是常危险的东西。铅笔需要削的，铅笔屑-是导电的，在失重情况下会飞得到处都是，而且那儿都能进，对电器设备是极大的威胁。人吸入铅笔屑，也不是见好事。即使不削，铅笔也会在使用的过程中产生碎屑。当-时苏联人使用铅笔，并不是铅笔好用，而是迫不得已，或者权宜之计。为了赶紧度。从长远来看，美国人的路线才是正道。事实上，这种权宜之计在苏联航天史上比比皆是-。第一位太空行走的列昂诺夫就差点因为这些权宜之计而永远留在太空。
> 再来看看MiG-23。MiG－23的分级变后掠翼的确简单很多。但是，它是否能够达到无极变后掠翼的效果呢？差得很远。请注意，这和肥皂盒案例有根本性的差异-。小工的方法达到了那些复杂方案相同的效果。但MiG－23不同，MiG-23差不多可以算MiG最失败的作品。尽管宣传上拥有很多光环，但是其实际战果和服役-记录，无论在两伊战争还是中东战争中，都是最差的，甚至还不如老旧的MiG－21。很显然，在天上，战斗机驾驶员已经有足够多的操心事，如果还要他们看着速度表-，心算着机翼的档位，不断地把手从油门杆上移开，操作机翼，那么这还能得到什么好的效果？事实上，MiG－23差不多是一架固定翼飞机。在实际飞行中，特别是在-空战中很少变换机翼。却背负着变后掠翼的重量。更糟糕的是，这种走捷径的方法迷惑了苏联（领导）人，以至至今也没有真正意义上的变后掠翼战斗机。
> 反观美国人，傻兮兮地硬啃自动化的无极变后掠翼，结果F－111A流产。但钱没有白扔，从F－111A的废墟上重生的F－111B成为了最成功的远程攻击战斗机-。而在此基础上发展而来的F－14，则是一代名猫，甚至在演习中打败了f-15。粉丝遍及天下。去年方才光荣退役。
> 我抬这些扛的意思是说，这些故事有的能够说明问题，但更多的并未表达出深层的意义，以至人们错误地理解。的确，简单是工程中最重要的原则。但是，简单不是绝对的-。在不同的时候，有着完全不同的效果。事物都有两面，简单也是一样，在拥有很好的作用的同时，也会带来某些副作用。我们只能辩证地分析问题，作设计。有时，简单-同时却又是复杂的。举个例子，有一种喷气发动机，叫超音速冲压发动机。结构非常简单，就是一个一头大一头小的通道。简单吧，但是其中的气流是极端复杂的，少有差-池，火都点不着。简单当中也蕴含着复杂的东西。比如python。语言是够简单的，但是设计简单的语言，可能比复杂的语言更困难。
> 所以说，简单不是绝对的。简单必须是恰当的简单。当我们制定一个简单的方案的时候，最好从反面思考一下，这是否是一个有效的简单。
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
莫华枫
嗯.理解.
我举这个例子,主要是说明,对于架构师来说,需要有效的进行模型的简化,否则对下一层的设计和实现会有巨大的压力和不好的影响.
但当然大家不能走到反面去...如果简化到影响了可扩展性和功能的有效性,那当然就完蛋了.
老莫是个真正的军迷,所以对MiG-23的设计有更好的意见,我那个是半瓶醋,只是用来说明架构师的责任的.呵呵.
莫华枫
2008/12/6 莫华枫 <longsh...@gmail.com>如果从另一面看一下这个故事，事情或许有另一种解释。为什么美国人没有用铅笔？美国人天生喜欢把问题想复杂？他们不知道铅笔可以在失重情况下使用？这有些太夸张了。我们再看一下，国际空间站上用的是什么笔？现在，根本不可能在空间飞行其中看到铅笔。包括俄国人本身的飞行器。因为那是常危险的东西。铅笔需要削的，铅笔屑是导电的，在失重情况下会飞得到处都是，而且那儿都能进，对电器设备是极大的威胁。人吸入铅笔屑，也不是见好事。即使不削，铅笔也会在使用的过程中产生碎屑。当时苏联人使用铅笔，并不是铅笔好用，而是迫不得已，或者权宜之计。为了赶紧度。从长远来看，美国人的路线才是正道。事实上，这种权宜之计在苏联航天史上比比皆是。第一位太空行走的列昂诺夫就差点因为这些权宜之计而永远留在太空。
再来看看MiG-23。MiG－23的分级变后掠翼的确简单很多。但是，它是否能够达到无极变后掠翼的效果呢？差得很远。请注意，这和肥皂盒案例有根本性的差异。小工的方法达到了那些复杂方案相同的效果。但MiG－23不同，MiG-23差不多可以算MiG最失败的作品。尽管宣传上拥有很多光环，但是其实际战果和服役记录，无论在两伊战争还是中东战争中，都是最差的，甚至还不如老旧的MiG－21。很显然，在天上，战斗机驾驶员已经有足够多的操心事，如果还要他们看着速度表，心算着机翼的档位，不断地把手从油门杆上移开，操作机翼，那么这还能得到什么好的效果？事实上，MiG－23差不多是一架固定翼飞机。在实际飞行中，特别是在空战中很少变换机翼。却背负着变后掠翼的重量。更糟糕的是，这种走捷径的方法迷惑了苏联（领导）人，以至至今也没有真正意义上的变后掠翼战斗机。
反观美国人，傻兮兮地硬啃自动化的无极变后掠翼，结果F－111A流产。但钱没有白扔，从F－111A的废墟上重生的F－111B成为了最成功的远程攻击战斗机。而在此基础上发展而来的F－14，则是一代名猫，甚至在演习中打败了f-15。粉丝遍及天下。去年方才光荣退役。
经典经典！:D 我虽不是军迷，但是这段看得我心向往之:P
Rui
这个例子还是不够典型呐.道理上讲你那C#的,用web.config配置masque跑的快慢速度,这个好象不是难事儿.要为这个再专门弄个XML,
不合算.
你这个具体问题,我们设计上有很严格的准则的,就是这种Magic Number(就你那500和200),绝对不允许出现在代码里.不管是C++的还
是C#或者JAVA的.一律得外部化,C++就弄个INI,C#就web.config或者exe.config,JAVA就xml.
On 12月6日, 下午9时57分, "莫华枫" <longshank...@gmail.com> wrote:
> 有两个案例，是我亲身经历的，说明了有时简单和复杂是连体婴儿，都是对方的影子。
> 第一个案例我以前说过。我们一个查询网站，用asp.net
> 做的，全本的C＃。倒霉的我，接收了。做网页是容易，贴贴控件，很快就好。这是简单。但是，那天当我在杭州湾边上的一家学校里实施的时候，用户要求一个maqu e跑得快些。结果，我不得不跑过半个校园，从同事那里取来笔记本，把500改成200，重新编译，然后拷贝到u盘，再拷贝到服务器上。里里外外半个多种头。
> 第二个案例，是前一个的延续。这个网站需要加功能，我就索性翻倒重来。用js＋jquery做网页，asp.net作为后端，访问数据。所有的查询存放在xml 文件中。并且利用sql2005的for
> xml生成层次化的xml数据，用xquery和xslt将其转换成html片段。结果，实施的时候，用户题出了一些修改意见，包括版面的和查询的。我们都现场 改好，最多的一个也就用了不到半小时。当天我根本没有带笔记本，一个u盘什么都搞定。
> 案例一中，C＃提供了一个构建网站的快速方法，但是在实际的应用中，却带来了更多的复杂性。而案例二中，我动用了不下五种技术手段，对于很多程序员（至少我身边 的那些）而言，足够复杂的了。但是，在面对用户变化的需求的时候，却使得问题更加简单。（我们不准用python，否则还要简单）。我那个混合了众多技术手段的 方案算是够复杂的，但是这些专用技术的组合却在总体上简化了问题。
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
Jun Yang
而是那种大巧不工的简单，是基于足够多的复杂思考之后给出的简化的，返璞归真的简单。
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
Rui
严重跑题严重跑题.
On 12月6日, 下午10时03分, "莫华枫" <longshank...@gmail.com> wrote:
> 2008/12/6 pongba <pon...@gmail.com>
>
>
>
> > 2008/12/6 莫华枫 <longshank...@gmail.com>
>
> >> 如果从另一面看一下这个故事，事情或许有另一种解释。为什么美国人没有用铅笔？美国人天生喜欢把问题想复杂？他们不知道铅笔可以在失重情况下使用？这有些太夸张 了。我们再看一下，国际空间站上用的是什么笔？现在，根本不可能在空间飞行其中看到铅笔。包括俄国人本身的飞行器。因为那是常危险的东西。铅笔需要削的，铅笔屑 是导电的，在失重情况下会飞得到处都是，而且那儿都能进，对电器设备是极大的威胁。人吸入铅笔屑，也不是见好事。即使不削，铅笔也会在使用的过程中产生碎屑。当 时苏联人使用铅笔，并不是铅笔好用，而是迫不得已，或者权宜之计。为了赶紧度。从长远来看，美国人的路线才是正道。事实上，这种权宜之计在苏联航天史上比比皆是 。第一位太空行走的列昂诺夫就差点因为这些权宜之计而永远留在太空。
>
> >> 再来看看MiG-23。MiG－23的分级变后掠翼的确简单很多。但是，它是否能够达到无极变后掠翼的效果呢？差得很远。请注意，这和肥皂盒案例有根本性的差异 。小工的方法达到了那些复杂方案相同的效果。但MiG－23不同，MiG-23差不多可以算MiG最失败的作品。尽管宣传上拥有很多光环，但是其实际战果和服役 记录，无论在两伊战争还是中东战争中，都是最差的，甚至还不如老旧的MiG－21。很显然，在天上，战斗机驾驶员已经有足够多的操心事，如果还要他们看着速度表 ，心算着机翼的档位，不断地把手从油门杆上移开，操作机翼，那么这还能得到什么好的效果？事实上，MiG－23差不多是一架固定翼飞机。在实际飞行中，特别是在 空战中很少变换机翼。却背负着变后掠翼的重量。更糟糕的是，这种走捷径的方法迷惑了苏联（领导）人，以至至今也没有真正意义上的变后掠翼战斗机。
>
> >> 反观美国人，傻兮兮地硬啃自动化的无极变后掠翼，结果F－111A流产。但钱没有白扔，从F－111A的废墟上重生的F－111B成为了最成功的远程攻击战斗机 。而在此基础上发展而来的F－14，则是一代名猫，甚至在演习中打败了f-15。粉丝遍及天下。去年方才光荣退役。
>
> > 经典经典！:D 我虽不是军迷，但是这段看得我心向往之:P
>
> 哦，真有这心思？我有很多这类杂志，要不要看阿？;-)
>
>
>
> > --
> > 刘未鹏(pongba)
> > Blog|C++的罗浮宫
> >http://blog.csdn.net/pongba
> > TopLanguage
> >http://groups.google.com/group/pongba
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/
Rui
就好比说厚书读薄那种意思.
并不是quick and dirty.
我觉得架构师需要那种敏感,就是这种简单是那种令人舒畅的简单..
On 12月6日, 下午10时05分, "Jun Yang" <yangjun...@gmail.com> wrote:
> 想强调一下哈，我理解的 在这里讨论的*简单*，应该并不是指那种为了快速解决问题，寻找捷径的简单。
>
> 而是那种*大巧不工*的简单，是基于足够多的复杂思考之后给出的简化的，返璞归真的简单。
>
> 2008/12/6 valpa <valpass...@gmail.com>
>
>
>
>
>
> > 十分同意你的观点
>
> > 做的复杂的过程本身就是积累，只有在不浮躁的环境下才可以做
> > 在目前社会这个氛围中，推崇简单也许是件好事情，也许不是
>
> > On 12月6日, 下午8时59分, "莫华枫" <longshank...@gmail.com> wrote:
> > > 2008/12/5 Rui <cao...@gmail.com>
>
> > > > 嗯.既然提到这个空盒子的.
> > > > 我也讲一个吧,也算Problem solving话题之一好喽.
>
> > > > 飞机设计上,机翼的角度决定了气动性能,高空高速战斗机需要大后掠角,低空低速战斗机需要小后掠角..
> > > > 那么为了制造适应于高低空战斗,同时具有速度和机动性的飞机(这也意味着既可以高速,还能省油..),变后掠翼就是一个大家都能想到的方案了.
> > > > 简言之,就是高速时后掠角增大.低速时后掠角减小.
>
> > > > 在60年代,苏联和美国几乎同时开始了变后掠翼飞机的研制.
> > > > 美国的办法是搞了一个自动控制后掠角和气动控制面匹配系统,简言之就是一个根据飞机气动环境自动改变后掠角的系统,达到了全部飞机包线的最优化.但这个
> > > > 系统实在是太复杂了.正搞的焦头烂额的时候,美国人发现苏联的MiG-23已经实现了变后掠翼飞机了.
>
> > > > 苏联人的设计令人崩溃的简单.
> > > > 内MiG-23的后掠角只有三个角度,16度,45度,72度.然后由飞机员手动去调节.....
> > > > 这就好比电风扇一样,美国人设计的是一个无级变速的风扇,而苏联人设计的是一个带档位的风扇.
>
> > > 这类故事还有很多。我这里还有一个更出名的：
>
> > 在早期太空竞赛的时候，美国人和苏联人都需要能够在太空失重环境下使用的笔。美国人花了几百万美金，终于开发出可以在零重力底下使用的圆珠笔。苏联人呢？他们用 -铅笔。:D
> > > 我要说的是，尽管这个故事基本上是真的。但是，如果想从中推断出美国人如何把事情高复杂，苏联人如何把事情高简单，以至于说明设计的思路好与坏，那就错了。
>
> > 如果从另一面看一下这个故事，事情或许有另一种解释。为什么美国人没有用铅笔？美国人天生喜欢把问题想复杂？他们不知道铅笔可以在失重情况下使用？这有些太夸张 -了。我们再看一下，国际空间站上用的是什么笔？现在，根本不可能在空间飞行其中看到铅笔。包括俄国人本身的飞行器。因为那是常危险的东西。铅笔需要削的，铅笔 屑-是导电的，在失重情况下会飞得到处都是，而且那儿都能进，对电器设备是极大的威胁。人吸入铅笔屑，也不是见好事。即使不削，铅笔也会在使用的过程中产生碎屑 。当-时苏联人使用铅笔，并不是铅笔好用，而是迫不得已，或者权宜之计。为了赶紧度。从长远来看，美国人的路线才是正道。事实上，这种权宜之计在苏联航天史上比 比皆是-。第一位太空行走的列昂诺夫就差点因为这些权宜之计而永远留在太空。
>
> > 再来看看MiG-23。MiG－23的分级变后掠翼的确简单很多。但是，它是否能够达到无极变后掠翼的效果呢？差得很远。请注意，这和肥皂盒案例有根本性的差异 -。小工的方法达到了那些复杂方案相同的效果。但MiG－23不同，MiG-23差不多可以算MiG最失败的作品。尽管宣传上拥有很多光环，但是其实际战果和服 役-记录，无论在两伊战争还是中东战争中，都是最差的，甚至还不如老旧的MiG－21。很显然，在天上，战斗机驾驶员已经有足够多的操心事，如果还要他们看着速 度表-，心算着机翼的档位，不断地把手从油门杆上移开，操作机翼，那么这还能得到什么好的效果？事实上，MiG－23差不多是一架固定翼飞机。在实际飞行中，特 别是在-空战中很少变换机翼。却背负着变后掠翼的重量。更糟糕的是，这种走捷径的方法迷惑了苏联（领导）人，以至至今也没有真正意义上的变后掠翼战斗机。
>
> > 反观美国人，傻兮兮地硬啃自动化的无极变后掠翼，结果F－111A流产。但钱没有白扔，从F－111A的废墟上重生的F－111B成为了最成功的远程攻击战斗机 -。而在此基础上发展而来的F－14，则是一代名猫，甚至在演习中打败了f-15。粉丝遍及天下。去年方才光荣退役。
>
> > 我抬这些扛的意思是说，这些故事有的能够说明问题，但更多的并未表达出深层的意义，以至人们错误地理解。的确，简单是工程中最重要的原则。但是，简单不是绝对的 -。在不同的时候，有着完全不同的效果。事物都有两面，简单也是一样，在拥有很好的作用的同时，也会带来某些副作用。我们只能辩证地分析问题，作设计。有时，简 单-同时却又是复杂的。举个例子，有一种喷气发动机，叫超音速冲压发动机。结构非常简单，就是一个一头大一头小的通道。简单吧，但是其中的气流是极端复杂的，少 有差-池，火都点不着。简单当中也蕴含着复杂的东西。比如python。语言是够简单的，但是设计简单的语言，可能比复杂的语言更困难。
> > > 所以说，简单不是绝对的。简单必须是恰当的简单。当我们制定一个简单的方案的时候，最好从反面思考一下，这是否是一个有效的简单。
>
> > > --
> > > 反者道之动，弱者道之用
> > > m...@seaskysh.com
> > > longshank...@gmail.comhttp://blog.csdn.net/longshanks/
>
> --
> yangjun...@gmail.comhttp://hi.baidu.com/yjpro
Jun Yang
相形而言，一个快速开发工具，的确更容易诱使人以简单的方式给出解决问题的方案，但是长期看却可能会有
巨大的成本。 能够操着快速开发工具，同时还能不拘泥于其中，则有赖于开发人员自身的修为了。
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
Rui
这个强制让程序员自己去把代码粒度做细,最终的目标当然还是实现pongba所说的,易于解耦.大块的东西很难分解,小块的东西容易组合.就这个意
思.
几个成功的开源项目,代码的简洁程度也是很高的,让人很赏心悦目的.
Jun Yang
来减少设计或是编码出现问题的可能。
代码质量如何保证？我的私人药方是，把一切事情简单化，尽量把代码写短（保持每个独立源文件不超过 500 行），删掉和缩减一切不必要的东西。让 bug 无处发生，比小心的回避它们要容易的多。不行就重写，而不要过多调试。不要在一块代码上耽误太多时间，速战速决。如果花了太多时间去实现它，那么一定有设 计问题。世界上有许多复杂的事情难以解决，但绝对不包括实现一个有特定需求的模块 :D 。
http://blog.codingnow.com/2008/03/lua_feeling.html
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
Tiny fool
--
--------------
Gmail: tiny...@gmail.com
Gtalk: tiny...@gmail.com
Msn: tiny...@hotmail.com
Phone: 13520711089
银杏技术咨询公司
http://www.yinxingtech.com/
Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm
TV的Google观察
http://www.tinydust.net/tinygoogle/
yq chen
Rui
MS的IDE最容易让人犯罪,就是养成画个BUTTON,然后什么都往OnClick里塞.
我为什么强调任何一个方法都不许超过25行,就是强制要求程序员分解.就算只是在方法层次分解(不引入新类),也比全塞到OnClick里好.
不过说到底,这不算是IDE的问题,还是用工具的人的问题.就好象不能说一个女孩子漂亮就应该QJ她一样.
> yangjun...@gmail.comhttp://hi.baidu.com/yjpro
Jun Yang
暗示着设计中存在潜在的缺陷(设计一个特定的算法模块需要引入的技巧性trick除外)，这个时候，最好是暂停
手上的coding工作，站在更高一层的角度来思考设计出现问题的可能，以及重构设计的必要性。
不过，我这样的想法有些理想化，对于从头设计一个系统，有足够的时间资源的情况下更适用一些。
对于Bug fix，小的代码模块的编写，可能就未必适合了。
不同类型 的项目，关注点有所不同，评估的标准也不一样。
兵熊熊一下，将熊熊一窝。套用一下，coding熊，熊一砣，设计熊，熊一摊。 ~
--
yangj...@gmail.com
http://hi.baidu.com/yjpro
Rui
一般如果coder遇到需要引入一些trick解决问题,往往是由于程序员需要某个东西,但这个东西却不能方便的从给定的接口中引入.这多数是架构设计
上有问题了.
理想的设计系统,每层只考虑自己的事儿,不应该跨层操作的.
On 12月6日, 下午10时27分, "Jun Yang" <yangjun...@gmail.com> wrote:
> 有同感。另外个人还有一点想强调的就是，发现coding的时候有些地方需要引入一些trick来解决问题，也往往
>
> 暗示着设计中存在潜在的缺陷(设计一个特定的算法模块需要引入的技巧性trick除外)，这个时候，最好是暂停
>
> 手上的coding工作，站在更高一层的角度来思考设计出现问题的可能，以及重构设计的必要性。
>
> 不过，我这样的想法有些理想化，对于从头设计一个系统，有足够的时间资源的情况下更适用一些。
>
> 对于Bug fix，小的代码模块的编写，可能就未必适合了。
>
> 不同类型 的项目，关注点有所不同，评估的标准也不一样。
>
> 兵熊熊一下，将熊熊一窝。套用一下，coding熊，熊一砣，设计熊，熊一摊。 ~
>
> 2008/12/6 yq chen <mephisto.760...@gmail.com>
>
> > 不错，超过150行以上的代码后来自己都不想去看了。出现这样的问题，主要是自己没有理清楚关系就下笔了。
>
> --
> yangjun...@gmail.comhttp://hi.baidu.com/yjpro