应用软件的组合技术：用 XML 描述你的框架（一）

第一次创建窗口对象是在Turbo C 2.0流行的时代完成的，至今还对操作VGA之类的代码留有印象，那个时代的编程与今天完全不同，1993年我开始接触WinSDK，当时，Microsoft还没有商业版本的C++编译器，Microsoft C的版本是5.1，大多数工作是命令行模式的，与今天截然不同。印象最深的是接触“窗口类”的概念，最初真是感到“莫名其妙”，没有C++的年代进行Windows编程真是令人痛苦的事情，但同时也是“痛并快乐着”……，与过去相比，今天的开发者真是幸福，琳琅满目的技术书籍、各种名目的开发社区，所有这一切，在上个世纪九十年代初期，真是无法想象。

我的第一个所谓的框架，现在已经没有了，当时形成框架的时候，颇有自豪感，那么多的C++代码，足够向人炫耀的！经过无数次的磨练，构造窗口的技术应该是可以过关的，但同时也变得麻木了，经常CreateWindow，就如同经常吃方便面一样，味道真是“差极了”。我接触到的第一个商业C++类库是Stingray的GridPro，一个面向“电子表格”的专业C++类库，这是真实领略专业开发者风采的一次震撼性的接触，那的确是一种“高山仰止”的感觉。GridPro我一直保留着，在我早期的工作中，还可以见到其“影子”：

（曾经计划中的一个产品，但“无疾而终”了，其中， GridPro 是其中的一个重要部分）

专心致志的开始考虑软件也许是1999年后其的事情，一晃，7、8年了。这几天在整理工作的同时，也在回顾，能坚持7、8年，也算一件颇为自豪的事情，比起开发产品，坚持是更加可贵的。

         C++开发，是很辛苦的，与其他开发不同，C++无法“偷懒”，通常意义下的“可视化”设计对C++几乎没有用途，这也许是C++ Builder无法吸引大多数开发者的真正原因。Visual C++中的“Visual”，与Visual Basic中的“Visual”含义完全不同，因此，我理解Visual C++中的修饰词“Visual”并不是汉语中的“可视化”的概念。用Visual C++同样很辛苦。我做软件工程的年代曾经流行过一句话，即“三分业务，七分界面”，就是说，一个软件工程，真正的业务代码，也许就占全部代码的30%，那个年代，软件工程能够完整用C++开发完成的非常少见。今天的人们由于选择的多样性，C++领地在逐步的缩小，Java、C#、Delphi、PowerBuilder等等基本成了软件工程领域的主导工具，我始终认为，就语言而言，本质上，各种语言在形式上是差不多的，为什么会厚此薄彼？当年有一个十分“不忿”的想法，就是，一定要用C++做出点什么给这些流行的工具“看看”，现在想起来，感觉很好笑。当Visual C++升级到4.0版本时，我基本上就被锁定到这个环境之中了，就开发环境而言，Microsoft风格的IDE也是那个时期就奠定了。就软件形式而言，Visual C++ 4.0-6.0的IDE一直是许多开发者竞相模仿的目标，以致后来，Office风格、Visual Studio风格也一直是国外商业类库的主要风格，但对普通开发者而言，能够实现这类的技术，即使是现在，也会有许多“成就感”，但问题是，这些工作，本就不应该是开发环节的事情，我们中的许多开发者将许多宝贵的经历投放到这个环节，真正软件应该解决的问题却被这些“形式上”的东西掩盖了。

（一个看起来很华丽的软件 UI ，占据了开发工作的相当一部分工作量，其实这些工作与开发环节是无关的）

         如图所示，一个漂亮的软件UI，会倾注开发者许多心血，这就好比一套漂亮的衣服，本来是应该有一套与技术流程关系不大的构造方案，但事实却是我们却不得不为之Coding，人力、智力、时间、资金等成本就是这样的渐渐消耗着，对软件而言，也在重复着追求外在美的故事，每天都如此。有没有办法摆脱这一切？人要装扮自己，恰当的搭配服饰就可以解决相当一部分问题，那么，软件可以吗？能不能使软件开发的实质性工作与这类需求彻底隔离？其实，做软件的UI，应该与办一个“板报”区别不大，不应该是一个有技术含量的工作，许多人天生就很会办板报，但却不能很好的架构软件，其中关键是“技术因素”在作祟。就视觉方面而言，大多数开发者也许都不是这方面的“行家”，但华丽的UI的确令开发者向往，正所谓“爱美之心，人皆有之”。