<< 第五节：后RAD时代：领域的成熟 六、更远的将来（有限无责任预测） 再接下来，更为迎合这种面向领域组织团队并开发的工具便会出现。但这种工具不再期望整合各个领域的实现技术（注意我不是说“开发技术”），而是提供领域间的交付标准。或者更为直接地提供交付物。更多领域专精的公司受到关注（例如现在的macromedia），大厂商开始购并更多的专属领域的公司，以整合他们的业务。 更大的平台化产品会出现，远程的、分布的、可迁移的运算理论和解决方案被普及，而与此同时的，更细分的领域带来了更多的专属工具和专精人才，项目的整体规模扩张， ...
<< 上一节(插播) 四、后RAD时代：界面可视，到界面可描述 RAD过程与快速原型构建的理论直接相关，这种过程方法要求用户及早看到一个产品并试用之。通过用户对产品原型的体验与确认来固化用户需求，这个是应对用户需求变化的有效手段。 RAD过程方法在过去二十多年的时间里取得了不俗的成绩，这是显得易见的。VCL的成功，其一方面的原因也在于它迎合了这一潮流：我们可以通过快速地界面开发，来得到用户可确认的原型。 我认为这一过程中，“组件化界面－产品”之间可以快速演进是一个关键因素。 也就是说，开发人员可以基于一个“组件化界面”来持续开发， ...
<< 第三节 RAD之死与系统的复杂性 这个插播，是Shaofei Cheng在MSN跟我的一段聊天记录。关于这个话题，我在会后休息的时候，与很多朋友都谈到过，但限于现场，无法记录。正好Shaofei Cheng与我又一次沟通了这个，得以形成记录，也能反映一些我在“VCL已死，RAD已死”这个论题中有关架构的思想。故此公众，大家可以狂批…… 建议整篇文章从头读起，在这里在这里 Shaofei Cheng 说: ...
<< 第二节：分层，真的改变了你的思想了吗？ 三、RAD之死与系统的复杂性 RAD在较小规模应用的开发上，具有相当的优势。同时，它具有两方面特性： 对于应付在各个模向分层上需求相对均势，并且在开发工具商提供的方案可应付的区间内的需求中，RAD以及使用RAD开发的团队具有极大的能量。例如早期的C/S模式下的数据库应用。 对于系统可以纵向切分（为多个子项目或独立模块），而且各个部分满足上述第一项的特性时，RAD在应付这类系统的规模增长上也具有极大的能量。例如群件、或中间件等。 对于上述两个特性之外的系统，RAD的团队难于组织、管理，也难于复制。 ...
<< 第一节：从UI的变革到系统的复杂性 二、分层，真的改变了你的思想了吗？ 分层思想提出来了——这在操作系统的设计上可以上溯到上个世纪50年代，但在应用软件开发上却并不太久。一个比较稳定的分层系统是“交互、业务和数据”三层，当然，与实际需要相关的还有更多层、更多更多层。 分层没有什么不好。正如我说WIMP没有什么不好一样。但是，厂商们开始掺合了。为了让我们的程序员成为RAD中的SuperMan，以及表明我们这些厂商直接就是超人学校，并提供超人道具。所以我们的开发工具加上了各种各样的RAD工具：数据库可以拖、 ...
《VCL已死，RAD已死》 ——SD2C中未能尽言的话题 今年的SD2C，我匆匆去又匆匆还，因为有急事要处理，所以第三天的课程都没来得及参加。与此相同的是，我的那场话题，也讲得匆匆忙忙，有许多不清楚透彻的地方。其中之一便是这两个断言：“VCL已死，RAD已死”。 所以今次开贴重讲！ 一、从UI的变革到系统的复杂性 UI怎么构成？在Windows及同期的Linux、Mac平台上，对UI的解构是WIMP（Windows,Icons,Menu,Point）。这个抽象具有相当的合理性， ...
题记： 在与Ivar的访谈之后，我一直想把这一段过程写出来。我尝试拟过许多个题目，最后都写不成文章。几乎在我要放弃的时候，BLOG读者在评论中，对我所解释的“函数式语言”的置疑提醒了我：很多时候不是问题的答案令人置疑，而是问题的思想方法令人置疑。如同我问Ivar的问题，他的答案“令人怀疑的正确”，其实是思想方法的问题。不站在Ivar的历史，以及Ivar的成就的角度上去思考，你会认为Ivar是在应付我的责难。 事实上，那个访谈中，Ivar非常慎重地面对这个问题，并仔细地解释了他所提供的答案。可惜后来CSDN录制时，正好漏掉了这一段。非常遗憾， ...
这一篇发布于2007.04月的InfoQ首期中文版中。 问题 项目到了末期，总是长期、持续的维护。这种维护的工作甚至占到了整个周期的三分之二以上。而维护工作过程中会发生什么，是少有人讨论的，因为对于多数工程专家来说，这是在“项目结束之后”的事件。 在我看来，维护周期的产出有一种可能：后续版本。这种情况大多数会出现在自主研发的产品上；源于客户需求，也会出现在一些面向客户的项目中。此外，基于客户项目的产品化，也是可能的输出。 这些输出的共同点是：没有改变项目的实质，而是对项目的延续或者完善。因此， ...
引子 大概是因为列在博文的作译者清单里的缘故罢，我常常能在第一时间得到有关新书的消息。这本《移山之道》的消息在《大道至简》出版前我就知道了。当时也是心中忐忑，因为同样是一本言“道”的书，同样以愚公移山为背景，同样讲软件工程……邹欣先生在博客中说这“车”撞得他眼冒金星，其实我又何尝不是如此？哈哈～于是当时便想着：等《移山之道》出版了一定得好好看看，是不是好书不论，评论的心态要先调整好。。。。 还没想好怎么个调整法子， ...
《大道至简》的幕后故事共写了七节，其中的前五节都已经用BLOG的形式公开在CSDN上了。这里一次性的将全部的章节放出来，并做成了PDF文件。敬请下载。;) 《大道至简》幕后故事的全文PDF点此下载 新加的两节是： 幕后故事(6)：“愚公移山记”历史文化篇 幕后故事(7)：“愚公移山记”撰修杂事篇 此外，在这个PDF版的文件中，还添加了前后两版的“愚公移山记”作为附录，大家可以对照着看（因为撰修杂事篇》中讲到了很多未修改前版本的内容）。 PDF中也将《 ...
引子 上一节写的地理，这一节只讲策略。我自己读时，时时觉得《大道至简》一书写到末了，未见得有一篇古文精彩，只是这篇古文，愿细读的人并不太多罢了。 这篇军事谋略，与工程全然无关。你可以把它当作做人、做事或者做事业的参考，对于做工程，却没有什么意义。 顺便说，我没有读完过“三十六计”，我自己也不并是什么高明之士。所以，这些策略高妙与否，并不重要，也无佐证。读的人自作自想去便好了。 1. ...
引子 在前面我们已经讲到过“愚公移山”中的人物、事物，并且预告说现在这一节“军事地理”将非常精彩。但现在，这个精彩看来要打个折扣，因为这一小节只讲军事地理，不讲谋略，因此便只是一些背景性的文字交待，喜欢读的便读，不喜欢追根究底的，跳过去也可。 军事策略总是要与地理、环境等因素相关的，因此如果不先交待这些，那么策略也就讲不清。但所涉的国、域、地名和位置信息等都是古代的，所以就写得罗嗦了。大家姑且放开心情，当作历史书看看罢。 ...
引子 以古文述事，难点之一便在于我们对历史了解并不充分，因此常常把这个朝代的东西放在了那个朝代，或者让原本是甲做的事，说成了乙做。这样与史不合，容易使文章出笑话。这一篇“幕后”，便来说说“愚公移山记”中的事物。 不过由于这篇故事重在述事，所以对于“物”的描写并不充分，能拣出来谈的并不多，望谅。 1. 铁器 “愚公移山记”中对铁器的考证是一个非常令人痛苦的事。我从一开始便设想，到底有什么法子让愚公在太行山中挖出一条路来呢。然而思来想去， ...
引子 “愚公移山记”文言和白话两篇附录，是《大道至简》第二版中重要的组成部分。但我们这些读惯了技术书的人，大概是不会象文科生一样，一边考证着一边读古文，因此这篇“愚公移山记”中的背景，怕是没几个人会晓得。然而如果不了解这个故事的一些背景知识，那么读起来便不会有什么意思，不会知道其中的含义。 因此接下来的“幕后故事”，我将用一系列专题，来讲讲这个“愚公移山记”是如何写成的。 你可能不会想到，这将涉及到历史、地理、军事、 ...
一、大道至简与愚公移山 《大道至简》一书最初的领悟来自那张EHM图。这个故事我在书中已经讲过：在一次Delphi.NET培训的准备工作中，我顿悟“语言只是工具”，并由语言的工具本质为起点，透视了整个软件工程体系。这张图后来被补充为“软件工程层次模型（EHM）”。而从这张图起，我便有开始为我的这些想法写出一本书来，而书的名字就是《大道至简》。 我写书是从前言开始，在写《大道至简》的前言（第一版的“前言后语”）时，我并没有想到从哪里开始写整本书。 ...
