Chandler从XML幡悟过来

Saturday, August 13, 2005

Chandler begins recovery from XML

 

官方版终于出来了。Chandler的parcel xml格式(parcel xml format) 如今遇到了批评声并将变得越来越多，而简单的Python API会彻底取代这种格式。有些人会回想到我以前在Python Is Not Java rant一文中曾说过像这样在应用程序核心功能部分使用XML并非是明智的选择。:)在PyCon Chandler sprint，Chandler本家的XML schema定义语言对于开发人员已被认为是个很大的难关，所以我建议用基于描述符的Python API来取代它。这项移植工作已于近期完成了。此后就只有数据项初始化部分（如Chandler的用户界面组件）是使用XML做的了。因此就在几周前，我实现了一个用来初始化数据项的实验性的API，并很快受到了广泛欢迎，甚至有人还指出了其可以处理循环的优点。

之后也有人提议说为用户界面定义创建一个新的XML格式。但由我提出的使用简单模版类和类方法来取代它的反对意见得到了更多地认同。

很多人误解并/或误传我过去对于XML的观点：Chandler这个例子应该有助于澄清这件事。Chandler仍在将XML用于WebDAV、.xrc文件和共享等许多其他能够这样做的地方。可是，parcel xml格式纯粹是一项消费税：一个使用起来的冗长累赘的语言，而用Python代码完全可以做得更加简洁（且高效）。它被开发成为一个“数据驱动”系统来为Chandler的前途服务并有望最终会支持GUI编辑器一类的工具。

当然，由于过度的设计超出了需求范围，真正的错误并不完全归咎于XML本身。如果你现在没有在开发特性，那么最好不要基于你所认为的将会需要何种特性来做出一些其它设计上的决定。即使是选择用XML形式处理数据这样一类小事情也会导致各种各样额外的代价，比如：

 

·           设计XML格式

·           实现一个解析器

·           使格式文档化

·           开发格式中的一系列要素

·           更新和修补解析器来处理越来越多以前未曾想到的复杂用例

·           出现Python不会出现的效率降低的情况

·           一旦发现思路不对便转换所有数据，否则就得为正在产生的销售和教育成本或是没能从忙碌的程序员身上得到成果的成本买单，以便在困难时期得到第三方程序员。

 

这些本来不该增加的东西的成本真的实在是太高了。幸运的是OSAF认为做对事情要远比把钱不断投入到去证明花出去的钱都没白花重要的多。然而，我当然也在对此持相反态度的机构干过，包括曾经砸了几百万美元到一份昂贵的“企业级”的骰子上面，设法以此取代一个小巧、设计精良的Python程序。哈，我本可以在那个预算之下搞定的！当时可能我要是给大伙加薪或雇用更多的人就能完成了，或把我这个小组改造成一个能够将软件卖给其他公司的团队也许就好了。埃，我们本应用这些钱去为团队成员多买一些日常喝的免费碳酸水使其为投资方创造更多价值，而不是像当时那样的花钱！

我离题了。总结起来只有一句话：延期的特性投入是好的，隐性成本的谬论是糟糕的（delaying feature investments good, sunk cost fallacy bad）。还有什么问题吗？

 

（原文链接网址：http://dirtsimple.org/2005/08/chandler-begins-recovery-from-xml.html）