转的滥文: VCL已死，RAD已死. + 我的评论

这是转载的文章, 典型的标题党, 狗日的.

VCL已死,这个是肯定的,

但下文的分析却是混乱的.

VCL的死与 borland 有极大的关系, 设定行业标准是需要一个强大的公司, 可惜 borland 后来没落了.

市场的格局是怎样的, 有许多因素, 走到今天的样子都是市场的参与者各自图利的结果

些是偶然,有些是必然. 有些偶然的事情影响到后来的发展, 影响了新的必然

如果仅仅是因为设计师在HTML+CSS下更自由地表现它的理念,

那么浏览器的作用就没有分析到吧.

HTTP的网络最开始也是没有这么[多媒体]的,图片都没有更不用提视频.

市场是有惯性的,这也是必需要考虑的.

等等, 原因非常复杂;

但做再多的假设,也没有意义了, 无法得出有用的结论徒增困惑!

历史就是历史.

多读读历史,不犯前人的错误 , 做到这一点,就足够了.

=====================================================

——SD2C中未能尽言的话题

今年的SD2C，我匆匆去又匆匆还，因为有急事要处理，所以第三天的课程都没来得及参加。与
此相同的是，我的那场话题，也讲得匆匆忙忙，有许多不清楚透彻的地方。其中之一便是这两
个断言：“VCL已死，RAD已死”。

所以今次开贴重讲！

一、从UI的变革到系统的复杂性
－－－－－
UI怎么构成？在Windows及同期的Linux、Mac平台上，对UI的解构是WIMP（Windows,Icons,Menu,
Point）。这个抽象具有相当的合理性，并一度带来了GUI的繁荣。然而，界面技术本质上是掌
握在平台技术厂商的手上，例如Windows提供MFC，大家便只能在这个MFC的基础之上来构建GUI
应用。所以Delphi早期的成功，就是把MFC变成了更便捷的编程形式来替代，尽管其本质上还
是MFC框架下的UI，但就是比后者方便，从而有了RAD（快速应用开发）一说。

同样的道理，Java做了自己的平台，将虚拟平台与操作系统平台隔离开。于是，在Java之上有
了Swing或jFace等等，应用提供商也基于这样的平台来做开发，出来的界面仍然是在同一个风
格体系之下的。

我们现在来看一个软件产品，它是Delphi写的，还是VC写的，或者是Java写的，也或者是在Linux
上基于某个GUI包做的，在很多时候从界面上一眼就看得出来——因为他们其实是不同平台上对
WIMP的实现。然而，我们来看WEB，便没有这种的倾向，WEB精彩纷呈，不同的网站有各
自不同的特性。没有了所谓“软件产品”的基本面貌，似乎没有人愿意承认“WEB网站”是一个
“软件产品”。

但是，仔细分析WEB UI，你会发现它的本质结构是“块+层+链接”。“块+层”是表现上的本
质，这与Photoshop等作图工具是完全一样的。所以，只要能用Photoshop画出来，就能用HTML
做出来，这二者之间基本是可以等量转换的——因为这二者本质相同。同样的，“链接”是用
户UI交互的本质，也是WWW的本质。Mac系统可以让鼠标只有一个键，本质上也是这个道理。用
户行为，只需要点击一个位置来触发，而不需要位置上的二义性。如果需要另一个含义的行为，
那就换一个位置（例如按钮），这个，是“简化UI”或“人性化UI”的本义。

所以，事实上WEB的成功，与WEB UI比传统的WIMP UI更加人性，以及更加面向设计师（例如PS
高手）有直接的关系。而另一个方面，RAD的出现，与WIMP则有密不可分的关系——WIMP抽象了
界面的“可组件化的基本要素”。

UI的变革带来了最直接的问题：使用WIMP的思想，开发不出WEB UI。最明显的例子就是Delphi
的没落。事实上，这中间也包括Virsul C/C++的没落。二者相同的在于，原本“可视化编程”
优势变成了劣势。

这是为什么？

什么叫“可视化编程”？Delphi/VC/PB/VF...这一类的开发工具中，你可以把一个组件拖到窗
体上，然后配置属性、添加行为、处理逻辑代码，然后“RUN”。一切就OK。这就是“可视化
的”、“快速的（RAD）”编程。然而注意一个事实，这个过程要求一个“程序员”的全程参
与：界面设计工具与代码开发工具在同一个环境中，不可分离。

所以，在RAD的时代，我们的UI设计师是要迁就软件开发人员的。UI设计师设计了界面，然后
开发人员说：荒唐！这样的界面用Delphi根本做不出来！然后一切就推掉重来。客户端软件
产品的开发，就是在设计与开发人员的战斗中一路走过来的，而且，通常是开发人员取得胜利。

开发人员不会做界面。真正会做界面，需要有相当高的图形程序开发功底，于是，那些有这样
功底的人开始做组件，例如很漂亮的换肤控件。这——看起来漂亮了，但是仍然不是界面设计
师理解中的UI。

从中暴露出来的表面问题就是：开发人员最好是superman。RAD开发中的程序员，最好就是精擅
各门的大家。无论是网络、数据库、图形、操作系统还是所有的一切，你最好都懂，最专长。
这样，一个模块给你，你完全搞定，大家都放心。因为RAD嘛，你搞不定，是不够快速，是工具
不够好，或者你不够super。

然而，我们的系统已经越来越复杂，已经越来越不是“一个人”能干的活儿了。


二、分层，真的改变了你的思想了吗？
－－－－－
分层思想提出来了——这在操作系统的设计上可以上溯到上个世纪50年代，但在应用软件开发上
却并不太久。一个比较稳定的分层系统是“交互、业务和数据”三层，当然，与实际需要相关的
还有更多层、更多更多层。

分层没有什么不好。正如我说WIMP没有什么不好一样。但是，厂商们开始掺合了。为了让我们的
程序员成为RAD中的SuperMan，以及表明我们这些厂商直接就是超人学校，并提供超人道具。所以
我们的开发工具加上了各种各样的RAD工具：数据库可以拖、网络接口可以拖、应用框架可以拖、
设计模板可以拖。厂商们宣传：只要往界面上一拖，我们的开发人员就可以回家睡大觉了，三天
后系统就可以Build出来。

老板们相信了这样的鬼话，并且认为那些没有按这样的方式为客户“生产”出产品的程序员都是
笨蛋，应该立即开掉并招聘另一批RAD的SuperMan进来。按照RAD对时间节省的功率来看，客户给
出的时间富富有余，重复开发三五回都没问题。

但是，结论是：我们失败了。在所有的分层上，由同一个厂商，在同一个工具，使用同一个或一
类开发人员来完成产品的理论和实践，通通的倒掉，死掉，一个不留。

没有人是超人，没有人能象孙猴子那样从天上打到地下，从龙宫打到阎罗殿。我们是在写软件，
不是在制造神话。相信这一点，你就知道在各个分层上由同一方案来解决是不合理的。分层是伟
大的思想，只是工具产商们胃口大到了极点，因而无视于这伟大思想背后的深意。

纵向的切分带来了模块与模块间的隔离，可以将系统由大而化小，从而分解了“系统的复杂性”，
这与把一个住宅小区分成几十橦大楼，以及无数的生活设施是一个道理。同样的，横向的切分带
来了专业领域，以及领域间的界面，这与把楼房看成砖瓦等构件是一样的。但砖瓦等构件带来的，
是砖头工、瓦匠，以及木工、电工。无视于领域存在的人，只配去建猪舍，在那样规模的建筑上，
不需要“术业有专攻”，而且项目失败成本的边界无过于：

压死一头猪，或一群猪。

大厂商们以牺牲一头或一群猪的风险成本与战略眼光，以及战术思想，要让我们——开发人员去
建设一橦大楼，或一片小区。这就是现实。

分层，带来模块的分解，以及领域的切分。而你的求职简历上还写着：熟悉二十种语言、各种开
发工具、设计工具、调试环境、性能分析测试以及服务器端部署……

开玩笑啊，如果你的工作经验未能超过150年，而你的老板还敢雇佣你，那么活该他项目做死掉。


三、RAD之死与系统的复杂性
－－－－－
RAD在较小规模应用的开发上，具有相当的优势。同时，它具有两方面特性：

1、对于应付在各个模向分层上需求相对均势，并且在开发工具商提供的方案可应付的区间的需
求，RAD以及使用RAD开发的团队具有极大的能量。例如早期的C/S模式下的数据库应用。

2、对于系统可以纵向切分（为多个子项目或独立模块），而且各个块满足上述第一项的特性时，
RAD应付规模增长的系统时，也具有极大的能量。例如群件、或中间件等。

对于上述两个特性之外的系统，RAD的团队难于组织、管理，也难于复制。显然，RAD对个体特性
的要求过高，不利于团队的成长。大公司的高人们，难道真的没有看到这一点么？

不是，他们看到了。VS.NET开始把产品做成产品线，发布开发产品的不同版本：设计师的、架构
师的、测试工程师的……等等这些。与此相同的，各家都开始这样切分产品。但是相同的产品线
名称迷茫了开发人员：大多数时候，我们要么选用不分这种版本的早期产品，要么选用这种产品
的最完整版本。而后者，正是大公司的销售经理最喜闻乐见的，他们会相互吹嘘自己买出去多少
个Site Suite版本，并同时拿Web Devleper版本的业绩来开涮。同时，大产商也不会无视市场的
价格而鼓吹单一版本，因为那样的结果是：“网页制作应该用macromedia的”、“图形设计应该
用adobe的”、“数据库得选Oracle的”、“服务器最好用Linux便宜”……

拆开来买的“大”产品，虽然不至于一文不值，但至少没大产品值价。这个与传统产品不同，其
根源在于开发工具的“大”产品没几家做得出来，而“精”却很多人能做得到。大公司可不会为
了理论上的正确性而无视于市场盈利。

所以大厂商对RAD工具的细分其实只是假象，用来说明他们的工具足够牛足够大和足够好的一个
旁证。这些“细分”的背后是极强的相互依赖性，结果是：整个解决方案还是一家独大。

我认为，系统的复杂性需要横向的切分来分解。因为横向的切分产生的是领域，与之对应的，就
是不同领域、产业的力量，而非某个个人或团队或公司的力量。不同领域、产业带来的，是整体
性的推动，而不是某个个体的畸形发展。同样的，他也带来了个体品质的提升，例如有了最好的
砖瓦匠和水电工，也带来了在更高分层上独立思考的可能性，例如建筑师与城市规划设计师。

当然，我相信很多人认为自己拎上一把锤头就可以做水电工——我前两天在CSDN论坛里就看到了
这样的观点，我也相信很多人认为建筑师与城市规划设计师都是饭桶，他们存在的目的仅仅是就
业安置或者消耗粮食。我完全相信这种观点的存在，但不同意它。我曾经做过电工，我知道用一
把锤头敲击就听出设备的好坏是需要10年以上的功夫的；我也知道如果没有规划师，城市会比现
在更乱而不是更好。

你可以批评别人做得不够好，但把你放在相同的位置上，你未必做得更好。这与横向分层理论带
来的效果是一样的，你可以认为自己能做好所有层次上的工作，但你真要去做的时候，却未必做
得到。以及，由于你——这个个体不能被拆分，所以你的工作是串行的、效率是有限的，结论正
是：在这样的思想下，大的系统会越做越糟糕。

横向分层带来的结果要变成良性的，就必然是相信每个层面上有相“匹配”的人员。你要信任它，
并主动合作，你要相信团队是一个多层结构，相信团队中的其它人会给你帮助，以及需要你的帮
助。你做不到一切，你依赖于别人而达到你的成功。

同样的，你也必须认识到：没有任何一个团队一开始就是这样的。团队需要清理，需要沉淀。需
要花费一些成本来建立沟通，并逐渐形成合作的模式、默契。当然，另一种更加不错的方式是：
整个教育和培训行业相信这一点，在程序员走向商业产品开发之前就培养他们的团队组织与协作
能力，从习惯于服从和配合，到学会观察与学习，以及在团队中如何自我提升。等等这些，才是
我们传统行业——例如我们常常提及到的建筑行业中的职业进化模式。

产业的、领域的推动才会解决系统复杂性的问题，而不是某一个或几个大公司在他们各自有限的
领域中折腾。他们折腾的目的、根本只是为了商业利益，而不是为了解决问题。



这个插播，是Shaofei Cheng在MSN跟我的一段聊天记录。关于这个话题，我在会后休息的时
候，与很多朋友都谈到过，但限于现场，无法记录。正好Shaofei Cheng与我又一次沟通了这
个，得以形成记录，也能反映一些我在“VCL已死，RAD已死”这个论题中有关架构的思想。故此公众，大家可以狂批……

建议整篇文章从头读起，在这里在这里 -->>>



Shaofei Cheng 说:
UI设计师设计了界面，然后开发人员说：荒唐！这样的界面用Delphi根本做不出来！
Shaofei Cheng 说:
我觉得这段蛮有意思
Aimingoo 说:
是啊，真的常常这样。
Aimingoo 说:
在WIMP模型上做UI是受限的。而在块+层的模型上做，跟PS的实现过程非常接近，所以基本
就不受限。
Aimingoo 说:
这个，才是WEB UI流行的根本原因之一。当然，WEB自己的力量也是原因之一。
　

Shaofei Cheng 说:
我觉得没有做不出来的界面 只有工期内做不出来的界面
Shaofei Cheng 说:
所以最后程序员能做出来的界面 是和底层依赖的库/开发工具/框架关系很大的一个范围
Shaofei Cheng 说:
我一直觉得这一点很有问题的
Aimingoo 说:
是的。
　

Shaofei Cheng 说:
很多人都感叹 要是能同时用prototype和Jquery多好
Shaofei Cheng 说:
有些问题在prototype里面一句话就解决了 有些问题在Jquery里只要几个字母
Aimingoo 说:
哈哈哈~~
Aimingoo 说:
不需要，在我看来，应用逻辑的开发人员，与UI及控制逻辑的开发人员应该是两个。
Aimingoo 说:
如果是一个，这个人就得向superman靠齐。
Shaofei Cheng 说:
嗯
　

Shaofei Cheng 说:
关于这个 不知道你了解过WPF的开发模式没有
Shaofei Cheng 说:
VisualStudio + Expression Blend
Shaofei Cheng 说:
VisualStudio给程序员用
Shaofei Cheng 说:
Expression Blend给UI Designer用
Shaofei Cheng 说:
我猜你会有点兴趣
　

Aimingoo 说:
我了解过。。。
Aimingoo 说:
后来还提到了。只是你没明白 ，我认为这样根本解决不了问题。
Shaofei Cheng 说:
哦？
Shaofei Cheng 说:
你怎么看呢？
Aimingoo 说:
横向分层，划分领域。
　

Shaofei Cheng 说:
界面和程序分开么？
Aimingoo 说:
是。
Aimingoo 说:
真正、彻底地分开。
Shaofei Cheng 说:
那么现在WPF已经是这样了
Shaofei Cheng 说:
XAML是由UI Designer出的
Aimingoo 说:
但是，在没领域的情况下，用WPF+分层思想做产品的仍然是同一个或同一批人。
Aimingoo 说:
这是提高不了效率的。
　

Aimingoo 说:
这篇文章有三节，你看了几节了？
Shaofei Cheng 说:
都看了
Shaofei Cheng 说:
感觉不是特别catch你的观点
Aimingoo 说:
你应该去了解一下，有几个UI设计师是用Expression Blend的？有几个是了解XAML的？
Shaofei Cheng 说:
呃 我们Team现在的UI......
Shaofei Cheng 说:
被逼迫着学呢
Aimingoo 说:
在一个使用了Expression Blend的团队中，UI设计师在哪里？在不在团队里？
Aimingoo 说:
他与团队是什么关系？
Shaofei Cheng 说:
在团队里啊
Aimingoo 说:
如果UI设计师被逼迫着放弃PS，而使用EB，你应该这是合理的吗？你认为开发人员团队，对
UI设计师称“他们”，是合理的吗？
Aimingoo 说:
不对的。UI设计师应该是我们，是与开发人员在一起的一个团队成员，是一个体系下的。而
且，他们应该使用不同的工具，使用不同的语言交流交互。
Aimingoo 说:
没必要要求他们在工具上趋同。关键在于他们如何配合，而不是是否使用相同的工具。
Aimingoo 说:
在盛大，设计师是在“设计中心”的，而开发人员是在“技术中心”。所以，事实上在某个
具体团队里，设计师是“外来户”。
　

Shaofei Cheng 说:
然而工具总是必须一致的
Shaofei Cheng 说:
就好像我们现在的Team 开发必须用VS一样
Aimingoo 说:
哈哈~~
Aimingoo 说:
Team为什么“必须”用VS呢？
Aimingoo 说:
是team的需要吗？或是公司高管们需要？
Shaofei Cheng 说:
因为要协同工作
Aimingoo 说:
给你们选择，如果能有自主的环境，你们是否一定会选择VSTS
Aimingoo 说:
协同的是人，不是工具。工具只是辅助来做这件事的。
　

Aimingoo 说:
我们可否有别的选择？
Aimingoo 说:
一个例子是，你让UI设计师如何用VSTS来跟“你们的”团队协作？
Shaofei Cheng 说:
嗯 可是Team必须在某些东西上统一
Shaofei Cheng 说:
你没法追求绝对自由
Shaofei Cheng 说:
比如假如一个Delphi团队里我突然说 我想用C++
Shaofei Cheng 说:
这是不可能的
　

Aimingoo 说:
你误会了我的意思。。。。
Aimingoo 说:
我那天在会场里讲，我说：混合语言的真实意义，不是在于让Delphi里面能用上内嵌汇编，
或用上C的二进制对象文件。这个是早期的混合语言开发。
Aimingoo 说:
这种混合语言，是以个体开发为核心的。
Shaofei Cheng 说:
嗯
Aimingoo 说:
我所讲的混合语言，是在领域分层上，在不同的层次上用不同的、最适合的语言来开发。
Aimingoo 说:
我看到的，例如UI上，我们用JS+DHTML或Flash来做，我们使用这种环境下最适合的开发工
具；在客户端，我们选Delphi，当然如何你的团队擅长VC，没关系，用就好了；
Aimingoo 说:
在服务器端，我们用Erlang，或是python,ruby。没关系，用就是了。
Aimingoo 说:
我们要把这三种不同的角色混合在一个团队中——解决一个大型体系的团队中，这才是混合
语言开发：在不同层面上使用最佳的方案。
　

Shaofei Cheng 说:
Markup+ Scripting+ Programming?
Shaofei Cheng 说:
你是指这种结构？类似这种的切分么？
Aimingoo 说:
不是确定的语言结构“Markup+ Scripting+ Programming”，而是层次隔离的思想。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
我就是说 类似于这种的切分方式
Aimingoo 说:
对的。
Aimingoo 说:
类似的。
Aimingoo 说:
从架构师的层面上来讲，关注的是某种具体切分的合理性。
Aimingoo 说:
比如你切成“Markup+ Scripting+ Programming”，我就需要考虑markup上是否有合理的表达。
Aimingoo 说:
是否能够能Script交互，是否能够在当前项目中切实可行。等等于此。
　

Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
那你觉得跟现在WPF做的有何不同呢？
Shaofei Cheng 说:
Markup有可能被替换成某种Binary
Shaofei Cheng 说:
Scripting也可能被替换成某种 Markup
Aimingoo 说:
WPF是要求了团队的结构，或解决方案的单一性。
Shaofei Cheng 说:
WPF应该说是一种具体的解决方案
Aimingoo 说:
我的意见是：用什么（例如WPF/XXX）并不是关键，而是在你决策之前，看看你的团队以及
目标是什么。
Aimingoo 说:
对的，WPF只能说是一个具体方案。而且我个人认为，传统的思想下会导致其成本更高，而
不是更低。
Shaofei Cheng 说:
嗯 取决于使用方式
Shaofei Cheng 说:
如果还是让一个程序员去写XAML 然后再写程序的话......
Aimingoo 说:
对了。从这个角度上思考，你就知道我在想什么了。
Shaofei Cheng 说:
尽管WPF在暗示大家把界面和程序分开
Aimingoo 说:
如果仍然是程度A去写XAML，然后A再去写程序，A再去关心部署，事情就根本上未有变化。
Aimingoo 说:
对了，WPF做了这种暗示，M$也在产品结构上做了调整。但是，商业利益问题决定了他们不
愿意向“开发团队”推动这种思想。
Shaofei Cheng 说:
从language和tool上都在暗示 但它本身并不是一个团队结构的约束
Aimingoo 说:
当一个使用PS的界面设计师进入团队时，他就成了外来户。
Aimingoo 说:
他用既有工具做不了任何事情，用自己的工具，又与团队的模式存在冲突。这是两难的事情。
　

Aimingoo 说:
真正分层体系上，比如说建筑领域里，砖工与瓦工是分开的，使用不同的工具与技艺，包括
交流的语言。
Aimingoo 说:
但这不妨碍他们在一起建筑。
　

Shaofei Cheng 说:
这个的话 我觉得是另外一个问题
Shaofei Cheng 说:
任何Team进了新人都会有类似问题
Shaofei Cheng 说:
但是你所说的这个分层 一定要有一个平台来实现
Aimingoo 说:
平台，可以是流程，可以是规则。
Aimingoo 说:
你还是开发人员思维。平台一定是VSTS吗？
Aimingoo 说:
一定是一个工具吗？
Aimingoo 说:
一定是一个软件产品吗？
Aimingoo 说:
平台，就是人+人+人+人~~
Aimingoo 说:
以及其上的一套规则和流程。如同建筑、工地、包工队。
Shaofei Cheng 说:
每一层的产品呢
Aimingoo 说:
对了，“每一层的产品”是个问题。但为什么“每一层的产品”都是M$出的呢？
Aimingoo 说:
M$想做这件事情~~只是他想做而已，为什么最终变成了开发人员的依赖呢？
　

Shaofei Cheng 说:
问题是 如果这个产品是文档
Shaofei Cheng 说:
一个夸张点的例子
Shaofei Cheng 说:
假如UX出了一份厚厚的 设计说明书 包括颜色、位图、交互的各种说明
Shaofei Cheng 说:
那么开发人员如何去用？
Aimingoo 说:
这是另一个思想。
Shaofei Cheng 说:
不 很相关的
Shaofei Cheng 说:
每一层之间用什么来交换信息 会直接决定这个结构是否可行
Aimingoo 说:
在人月神话里讨论过。
说到A团队与B团队的产品输出，早期的观点是B一定要看到A的全部东西，而后期、以及更合
理的观点是：不要看到A的全部东西，而只是关注如何使用它。
Aimingoo 说:
换言之，你上面的这个列表：厚厚的 设计说明书 包括颜色、位图、交互的各种说明等等，
基本上都不是要给开发人员看的。
Aimingoo 说:
基本上，那是UI设计人员的思想，以及思想的过程。
Shaofei Cheng 说:
对 是和这也也有关系 但是重点在于你提出的问题
Shaofei Cheng 说:
就是分层次解决方案
　

Aimingoo 说:
一个具体的UI实现者，应该与UI设计者一起工作，实现者问：这里要怎么动？设计者说，慢
慢地，由快到慢地……等等等等。
Aimingoo 说:
UI人员对“快和慢”是一种感觉，你不能要求他把这个写成一个公式或者数字，而且既然这
样做了，终有一天，体验人员会反对。
Aimingoo 说:
所以开发人员只需要在一个阶段满足他（UI设计师）的需要就可以了。通过这种对称的工作，
完成原始的模型，然后进入第一个开发迭代。
Shaofei Cheng 说:
那么 我觉得在你这个例子里 UI设计者成为了顾问的角色
Shaofei Cheng 说:
他的产品是持续供应的语言帮助
Aimingoo 说:
应该是顾问+素材提供者+需求方
　

Shaofei Cheng 说:
这个有点太具体了 你能让每一层都这样么？
Shaofei Cheng 说:
比如 一个专门作交互的程序员 和做业务的程序员 也如此协做？
Aimingoo 说:
用IVAR的例子，一个“骨架产品”是要花大量时间和交互成本、设计成本来建设的。
Aimingoo 说:
当骨架完成之后，具体施工时就只剩下了规则和具体业务逻辑。
Aimingoo 说:
举例来说，你认为现在城市施工中的“塔笼式建筑”，是一夜建成的么？
Shaofei Cheng 说:
当然我只能回答不是
Aimingoo 说:
当然不是，那是架构师、设计师、工程精英们在几十年的时间里总结出来的。
Shaofei Cheng 说:
赫赫
Aimingoo 说:
在这个框架之下，施工人员们现在只剩下了一套可复制的流程。
Shaofei Cheng 说:
这样的话 我觉得你所说的分层次思想就退化成了一种UX和dev协作方式而已
Shaofei Cheng 说:
我觉得UX需要一种自己的语言 可以被UX和dev接受的
Aimingoo 说:
所以，在我们上面的讨论中，UI设计人员与开发人员之间这种对称的、直接的沟通会发生在
某些原型的、骨架的阶段，但不是所有的阶段。
Aimingoo 说:
>>> Shaofei Cheng 说:
>>> 这样的话 我觉得你所说的分层次思想就退化成了一种UX和dev协作方式而已
这就是你的思想中最关键的逻辑问题了。
Aimingoo 说:
要注意，思想是思想，方法是方法。
Aimingoo 说:
你不能用思想去对等地讨论方法。
Aimingoo 说:
你只能强调：一种UX和dev协作方式，是分层次思想的一种实现方法。
　

Aimingoo 说:
明白了吗？
Aimingoo 说:
讨论某种实施方法的正确或错误是很简单的事：正确的东西换个背景就错误了。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
需要一个具体的场景
Aimingoo 说:
但是，分层的思想，以及清楚地认识到分层思想与纵向切分的不同。
Aimingoo 说:
最后，理解厂商们为什么做现在这些事，以及他们将来会怎么做……这一切与一个具体的场
景是无关的。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
但我觉得你说地UX跟dev那种模式并不好
Shaofei Cheng 说:
分层的优势应该是独立工作吧
Shaofei Cheng 说:
我是说 对于分层来说 非常不好
Aimingoo 说:
好，或不好，是要放在场景上去讨论的。
Aimingoo 说:
比如你的观点是基于你的现有工作场景，或工作经历。
　

Aimingoo 说:
分层的优势，是领域的推动。劣势，是沟通成本的增加。
Aimingoo 说:
层间交互的代价是极高的。必须在一个可以承受这种代码的环境中，才能使用它。
Shaofei Cheng 说:
领域的推动 就是更专业化吧？
Aimingoo 说:
我再举个例子。
Shaofei Cheng 说:
好
Aimingoo 说:
Erlang是用“节点、进程”这样的单位来切分一个项目的。
Aimingoo 说:
进程内，根据Erlang的设计，通过函数界面来交互；进程间，通过消息界面来交互；节点间，
通过端口界面来交互。
Aimingoo 说:
这各级之间的交互成本，是渐次递增的。
Aimingoo 说:
到了节点间交互时，端口交互成本就取决于网络环境。以Erlang早期的应用场景，也就是手
机平台来说，发个短信两分钟后收到，是很正常的事。
Aimingoo 说:
所以节点间交互导致的时延是可以接受的。对吧？
Shaofei Cheng 说:
嗯
Aimingoo 说:
但是，这样的系统不能用在PC环境中，因为如果一个企业的应用逻辑需要2分钟来交互——例
如老板按下一个按钮，要两分钟才反馈，大概是不成的。
Aimingoo 说:
这种情况下，ErLang并不胜任企业级的业务逻辑。尽管它并发、高负载……等等优势，他不
适合就是不适合。
Shaofei Cheng 说:
呃嗯
Shaofei Cheng 说:
然而这是程序间不同层的协作
Shaofei Cheng 说:
不是人之间吧？
Aimingoo 说:
但是，二十年后，环境变了。现在的端口交互的成本越来越低。
Aimingoo 说:
两台机器之间，光纤连接的成本都很低了。一张千兆卡，传输速度远远超过本机的硬盘I/O。
两台机器之间传递数据，比从本地硬盘读数据还要快。
Shaofei Cheng 说:
嗯
Aimingoo 说:
那么，端口交互的成本低到这种可接受的程度，所以ErLang渐渐地就被服务器端开发者们
看好了。
Aimingoo 说:
所以，我说“层间交互的代价是极高的。必须在一个可以承受这种代价的环境中，才能使用
它”。Erlang通过节点来分层，这种思路导致的交互代价可以被接受了，他就被接受了。同
时，他的其它优势才发挥了出来。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
great sample
　

Aimingoo 说:
同样的道理，我现在在讨论我们开发中的横向分层，必须是一个可以接受他的工程环境才能
用的。
Aimingoo 说:
你可用在一个RAD团队中使用横向分层，结果仍然是一个开发人员去做所有层上的事情，他愿
意去做，而且还很Happy。即使如此，他也要有消化层间交互代价的能力，他的项目或团队也
要有这种能力。
Aimingoo 说:
否则还是要做砸锅。
Shaofei Cheng 说:
所以说这个环境很重要
Aimingoo 说:
然而我之视见，我认为，消化层间交互的代价，可能不是一个开发人员能做的，而是领域推
动才能实现的。比如，我们有专业的设计人员，知道如何跟开发人员交互，如何构建原型——
但我要强调，这个设计人员一定不是开发人员！
Aimingoo 说:
只有具有了这样领域能力，他才能在这个团队中工作好。否则，我们就要给出时间，行业也
要给出时间来实现这些。
Aimingoo 说:
就好象在“塔楼式”建筑方式出来之前，我们还得用旧方法造楼一样。
　

Shaofei Cheng 说:
其实整理一下思路
Shaofei Cheng 说:
我一直在提WPF
Shaofei Cheng 说:
WPF是一个UI和dev协作的环境
Shaofei Cheng 说:
理论上讲 或者这个系统设计的初衷 就是让UX层跟dev层交互的代价变为0
Shaofei Cheng 说:
当然实际上他没有做到
Aimingoo 说:
是。
Aimingoo 说:
而且他还违背了UI设计者的初衷，他必须迁就开发团队地去学习VSTS。
Shaofei Cheng 说:
但是这是一个权衡的问题
Shaofei Cheng 说:
UI设计者被强迫用EB 也是一个限制
Aimingoo 说:
是的。如果这个团队的开发目标，锁定在VSTS可控的范围内，那么这样是可以接受的。
Shaofei Cheng 说:
或者说抛开工具
Shaofei Cheng 说:
UI designer必须提交一份XAML
Shaofei Cheng 说:
XAML工具有不少
　

Aimingoo 说:
你要具有架构师的思想，你必须认识到VSTS适合不适合，以及UI设计者被强迫用EB正不正确，
是一个具体场景的具体问题
。
Aimingoo 说:
他是一种权衡，这本身不具有正确性。
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
或者说WPF本身对项目来说是一个选择
Shaofei Cheng 说:
其附带的分层效果只是一个附加工具
Shaofei Cheng 说:
没法因为它的这种能力而选择它是吧？
Aimingoo 说:
我们再举一个例子。我在《大道至简》里面就讲过这个。
Aimingoo 说:
我说，我们的项目总有需求方，从开发人员的角度上来看，我们希望我们的需求提出者使用
C语言来描述它的需要。最好用C给开发人员写个框架。
Aimingoo 说:
对吧。但是，我们知道，我们的需求方大概不会用C，比如大企业的项目负责人，你不可能让
他用C。
Shaofei Cheng 说:
嗯
Aimingoo 说:
于是我们的工程界就说，我们需要一个标准的需求描述语言，例如说UML。这样一来，客户要
会用例图，开发团队（中的设计师）也要能懂它。
Aimingoo 说:
看起来一切美好。然而，客户不会用C，难道他就会用UML吗？
Shaofei Cheng 说:
嗯
Aimingoo 说:
你的问题和这个一样。UI设计师不会用C，难道他就会用XAML吗？
Shaofei Cheng 说:
嗯
Shaofei Cheng 说:
但是团队内和团队外不同
　

Aimingoo 说:
什么是最简成本的沟通？
Aimingoo 说:
注意，你的目标是UI设计师的设计可以被开发，你的目标仅仅是这个。
Aimingoo 说:
那么沟通的目标，就是“开发者+设计者＝一个可开发的产品”。那么让他们去保证这一点好了。
Aimingoo 说:
哪怕拿出来只是一个骨架，只要证明这个骨架可以持续开发就好了。
Aimingoo 说:
完全没必要通过一种XAML来保证。那是极大无聊的事情。
　

Shaofei Cheng 说:
那么至于究竟开发者去把位图写成XAML 还是UX去把设计写成C 其实只是一个开发时候的协作？
Aimingoo 说:
GOOD!GOOD!
Aimingoo 说:
我终于成功了，这太重要了。你必须明白，那只是开发时协作的一个可选工具！
Shaofei Cheng 说:
假如就有这么个变态UX 喜欢用C写设计 也是可以的
Aimingoo 说:
至于这个协作过程中，是用白板，还是在PS界面上画，或者是别的什么，并不重要啊。
Shaofei Cheng 说:
当时我想说 工具影响成本
Aimingoo 说:
所以，我从来不说我反对XAML，或反对UML。因为那原本就是一种可选工具。他是备选的，所
以我不能否定它。但是，我不能一叶障目地说我必须用它。
Aimingoo 说:
说必须用它的，是M$，是厂商，是业务代表。
Shaofei Cheng 说:
在工具设计者设想的场景中 这个东西保证了可行
Aimingoo 说:
>>> Shaofei Cheng 说:
>>> 在工具设计者设想的场景中 这个东西保证了可行
Aimingoo 说:
我同意。
但，那是他们的预想。
Aimingoo 说:
他们的预想只是一头猪或一群猪的代价。
Shaofei Cheng 说:
比如如果电脑上没有PS 图形技术没有出现
Shaofei Cheng 说:
UX只能把纸上的东西给开发者
Shaofei Cheng 说:
那么UX for software这个职业可能就不会出现了
Shaofei Cheng 说:
也不会有人提议将 软件的界面设计分成一层了吧
Aimingoo 说:
这个职业呵~~~ N早先就有。
Aimingoo 说:
要不你认为Windows是怎么做出来的？Mac？
Aimingoo 说:
哈哈。
　

Aimingoo 说:
基本上，到这里吧，我觉得你已经了解我想说的了。
Shaofei Cheng 说:
嗯
谢谢
Aimingoo 说:
对了，winter，我想把这段讨论贴出来。可？
Shaofei Cheng 说:
当然没问题
Shaofei Cheng 说:
跟你谈谈架构方面的东西很有收获
Aimingoo 说:
我整理下下。会比较清楚。
Shaofei Cheng 说:
嗯 继续后续预告：


四、后RAD时代：界面可视，到界面可描述

五、后RAD时代：领域的成熟

我的blog：http://szhaitao.blog.hexun.com & http://www.hoolee.com/user/haitao