emu in blogjava
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  171 随笔 :: 103 文章 :: 1052 评论 :: 2 Trackbacks
关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比

关于面向构件和EOS的一些思考
author:emu(黄希彤)
二、软件开发和传统行业应该怎么对比

 

        普元很喜欢把软件开发同传统产业进行类比，在接口问题上，我们也来看看传统的机械产业有没有类似的概念吧。螺丝和螺帽是我们最常见的两种构件，也是大规模工业化生产机械装置的基础，那么螺丝和螺帽的接口是不是宽松和自适应的呢？不是！他们是强耦合的接口，而且我们有上百万中不同规格的螺纹规格，或者说接口，每一种都定义的非常精确和有针对性。我们还有不计其数的齿轮的规格，有多少个齿轮可以用其他型号的代替呢？很少。当然机械装置中也有弱耦合，比如胶水、塑料、树脂。但是有没有利用弱耦合的结构来大规模生产机械装置的呢？我一时间想不出这样的例子。

 

        类比得出的结论是，如果我们要学习传统的机械产业，我们应该定制上百万种严格的强耦合接口标准，然后大量的厂商按照标准生产上百万种构件。看起来好像构件时代离我们还有点遥远哦。不过也未必，类比得出的另一个结果是，用EOS这样松耦合的构件来构造软件，就象用万能胶水粘到一起的一组齿轮、轴承和螺丝螺帽来做变速箱。

 

      我们不要理所当然的认为这样的变速箱没有用，这正是软件和机械的不同。这样一个变速箱只要设计合理、能够承载所需要的负荷，他是真的能够一直工作下去的，我们不需要面对金属疲劳、胶水老化和磨损这样的问题。也许这正是面向构件开发的实质吧：能用胶水粘到一起的东西，就不要用螺丝。

 

        是的，我的类比存在问题。再写上面这些文字的时候我脑子里面反复想起Jack Reecves的名言：源码就是设计，而软件的生产过程仅仅是廉价得几乎免费的构建过程。不错，我们可以机械化、自动化的生产大批的汽车、冰箱，可是我们还可以更容易的构建软件的拷贝。我们在抱怨软件的生产不能象汽车那样一台接一台的出厂，可是汽车厂又何尝能够一台接一台的批量设计汽车呢？

    昨晚码字之前喝了点红酒，思路好像不是太清晰，有点自相矛盾的倾向…author:emu(黄希彤)…

posted on 2005-06-21 09:04 emu 阅读(1381) 评论(8)  编辑  收藏

评论

# re: 关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比 2005-06-21 10:29 大胃
早期的软件的确是强耦合的，至少我从我学机械的父亲那里得到的印象是：那个时候做软件多少都有点机械工程的味道，我不知道这个感受是我的意象还是确实如此。

不过毕竟硬件/固件是固定的，具体的，绑在一起的实体；而软件则是流动的，不断变化甚至自我演化的流体。这个nature决定了软件可以有朝一日比硬件更容易摆脱接口（广义）的束缚，也更加容易升级。

另一方面，固件的日常维护是为了保持它的正常运转，需要的是让它完成既定的任务，或者更好的完成那些规定好的具体的事情，这些需求和它出厂时并无区别；软件则不同，我们经常需要根据新的需求来改变，通常是增加新的功能，所以维护软件需要有不同的approach。正是对软件这样的要求才出现了越来越多的低耦合的解决方案、设计模式和框架。

我父亲的时代也许倾向于用传统的机械制造的思维来思考软件的工艺流程和软件的本质，但是我发现这样的思路越来越行不通了。

// 昨天没睡好，也胡乱说一通......  回复  更多评论
  

# re: 关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比 2005-06-21 12:26 emu
固件？这个词在升级数码相机和mp3的时候用过，好像还是软件来的哦。

“用传统的机械制造的思维来思考软件的工艺流程和软件的本质”行不通吗？我觉得我们现在正是在软件开发过程栽进死胡同里面了，所以正需要从传统的机械、制造和建筑等行业学习人家的思维呢。我可以想像足够高的层次上，他们是相通的。  回复  更多评论
  

# re: 关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比 2005-06-22 11:56 小陆
软件的开发和传统的工业开发有很多不同之处. 软件开发是一种纯脑力劳动, 产品是一种无形的东西. 开发的过程是一个持续设计的过程, 从调查, 设计, 测试, 编码, 到部署和后期维护, 是需要持续设计的. 软件的开发过程中, 需求变化的程度要大于传统的产品, 并且软件构架的灵活程度也比较高, 一个系统的最初构架是可以发生渐变甚至突变的.
方法论也许很重要, 但是从根本上解决问题要提高人的素质, 调动人的积极性. 人本身对于软件开发的影响大大高于其他行业.   回复  更多评论
  

# re: 关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比 2005-06-22 12:21 emu
我认为相反，方法论比“提高人的素质, 调动人的积极性”要重要。在传统产业中是如此（比如零件标准化、生产流水线），在软件开发中也应该如此。我们遇到的困境就在于我们现在在软件开发中暂时还做不到、做不好。
确实，现在人本身对于软件开发的影响大大高于其他行业。这大概正是我们应该改变的现状。
  回复  更多评论
  

# re: 关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比 2005-06-22 13:59 小陆
软件生产的特殊性是无法摆脱的, 最大的特点在于需求的变化. 需求变化造成了软件的生产是一种持续设计的过程.

10年前工厂生产自行车, 把装好的自行车直接推进商场去买, 今天有专门的自行车店, 可以根据个性化的需要定制一辆自行车, 顾客可以试, 试过了还可以换, 这就是社会的进步. 尽管生产出来的自行车看起来没有什么变化, 但是客户的满意程度增加了, 同样也是增加了社会的财富. 对于这样的自行车店来说, 一个仅仅会在柜台里收钱的店员是没有用的, 需要的是具有多种专业素质的人.

软件的生产类似与自行车店里的工作, 不会直接的创造价值, 但是会提高顾客对解决方案的满意程度. 并且比传统的工业更加灵活, 更加适应需求的变化.

适用于流水线上的方法论基于一种基础: 人力和人力是可以互相代替的, 人力和时间是可以互相代替的. 在软件生产领域这个基础是不存在的. 建一栋大楼的时候我们可以认为, 加50个工人, 就可以提前一个月完工. 用这样的思想开发软件则行不通, 这样的方法论不适用于软件开发.

人本身对于软件开发的影响大大高于其他行业, 这个现状是很难改变的. 承认这个状况才能找出适用于软件开发的某种"方法论", 在这样的方法论中, 人应该在一个更加重要的地位.   回复  更多评论
  

# re: 小陆 2005-06-22 15:07 emu
好一个“需求变化造成了软件的生产是一种持续设计的过程”，和Jack Reecves的名言“源码就是设计，而软件的生产过程仅仅是廉价得几乎免费的构建过程”是一个意思。这恰恰就是我们难以和传统行业做重复相似的类比的根本原因。

软件开发至少在现在，和自行车店是完全没有办法类比的，也许在充分构件化开发的明天我们可以。

我认为流水线上的方法论并不基于你所说的基础，即使是什么经济学家说的，我也照样不同意。

我认为流水线的要点是把复杂的工作分解成很多小任务，每个（每组）人负责完成其中的一个或几个小任务。流水线之所以能够提高生产效率，是因为人在重复完成一个小任务的效率比完成整个大任务的时候生产效率要高，因为重复的小任务会变得熟练。

在软件开发过程我们没有借鉴过这样的方法论吗？我们不是几组人分工，需求分析、设计、编码、测试，象流水线一样在工作吗？我还把软件分成数据访问层、事务层、表现层来开发，这不是对流水线的模拟吗？我们没有因为这样的分解而增加了开发熟练程度和效率吗？

而且，软件开发中人力和人力也往往不是不可替代的（安德尔斯可能是个例外），我们都遇到过这样的情况不是吗？当然替换过程有个成本问题，传统产业一样也有。在这方面，我们的问题是能不能降低替换的成本，比如严格的XP开发流程中，这个问题就得到很好的解答。  回复  更多评论
  

# re: 关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比 2005-08-11 09:32 shuquan
普元是好事，但是还不是非常好：
基于jboss/eclipse两个免费的平台，整合出了一个东西来卖钱，让人感觉有点点不妥。
而且目标过于远大，不可能有银弹的。如果能提出一套控件的标准，ide以插件的形式分发，而不是把ide作为排他的东西（直接把jb/bea/idea等作为对手）.
应该有更大空间。（但是那样的话，普元如何挣大钱？好像可以卖标准哦）
由于该方向涉及东西太多，估计普元不可能都解决得了。因此，相信很多软件公司会分析、吸取普元的思想，自己搞得。  回复  更多评论
  

# re: 关于面向构件和EOS的一些思考－软件开发和传统行业应该怎么对比 2005-08-11 11:36 emu
不只jboss和eclipse是免费的，java也是免费的，但是我们都还在靠java混饭吃呢，这倒没什么不妥。

从来没有人证明过不可能有银弹，这也不是问题。目标过于远大？这更不成其为问题了。

剩下的问题我认为才是真正的问题。普元再强，你能强得过微软去？windows上面的软件大半不是微软出品的，用java开发的软件也大半不是sun出品的，可是普元上面的构件却基本上是普元出品的。虽然我们自己也可以开发构建，但是这不是一个开放的标准，我们如果这样做了自己的利益得不到保障，谁会去这样做呢？所以普元这个封闭的标准造成了他只能闭门造车，想帮他忙丰富他的构件库的人都无从下手。普元开发能力再强能开发出来多少种构件呢？

我觉得普元想做大，唯一的出路就是吧开发和应用环境都免费开放，最好干脆开源，并免费开放目前的大多数可以通用化的构件，在他的主导下创建并维护一个社群，让每个人都可以用EOS获取自己的利益，然后他可以以定制构件和生产出售在EOS平台上的软件来盈利。

如果他不这样做，我相信他的竞争对手迟早也会这么做。事实上，如果我是个没有生存压力的自由程序员，我现在也许已经在这么做了。

在他转向开放之前，我没有办法再看好他。  回复  更多评论
  


只有注册用户登录后才能发表评论。
网站导航: