这个插播，是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 说: 嗯
