每天早晨都是坐公司的班车上班的，从家到公司大约需要40分钟，这段时间不短也不长。为了打发时间，也曾经想过要充分利用这段时间，我选择过听音乐、看书。但音乐听时间长了就听烦了；在车上看书时间长了还有些头晕，所以多数时间我还是选择"思考"。"思考"的同时，眼睛也一直在"欣赏"车窗外的风景。今天窗外一处新楼盘门市的两个破碎的窗户让我的"思考"有了方向。

建筑物上的几扇"破窗户"，很多人即使注意了，也会不以为然。但是对于看过 Andrew Hunt 和David Thomas合著的"程序员修炼之道"一书的程序员们也许都会"见景生情"，因为在工作中身为程序员的我们时常(甚至总是)和"破窗户"打交道。

万事万物都是有其共同的规律的：建筑物上的破窗户、牙齿上的"小洞"、软件中的低劣设计、糟糕代码的等等，在其出现的初期也许并未显现出问题，但是如果你没有及时修复，建筑物上也许会出现更多破窗户、被丢了很多垃圾、被胡乱的信手涂鸦；牙齿上的洞洞越来越大，周围的牙齿也受到牵连，开始出现"小洞"；软件中低劣的设计风格被继承、糟糕的代码被复制并被散布到系统的方方面面，以至于到最后无法控制，或者是花费很大力气来修复。

面对"破窗户"，常有这样几类情形：
1) 无法识别"破窗户"；
2) 识别出"破窗户"，但不愿修复；
3) 识别出"破窗户"，有修复意愿，但"破窗户"难于修复，或者修复成本太高，或外部因素(时间、人员、成本)导致资源不足以修复这些"破窗户"；
4) 遇到"破窗户"，立即修复。
前两种情况，一个是水平问题；另一个就是职业素养问题了，这里不多说；我们常遇到的情况往往是最后两种，如果是最后一种，其实你是幸运的，多数这种情形下你从事的一个新的系统或者项目，没有太多的遗留代码，一切都在自己的控制之下，通过重构可以达到修复"破窗户"的目的；但是如果是第三种情况，那往往是最让人痛苦的-自己无法控制，即使有渴望有热情有能力去修复那些"破窗户"，但迫于系统庞大，业务复杂，时间有限而不敢轻易出手，更让人痛心的是，系统中"破窗户"的设计和代码渐渐传染给新人，新人在维护系统时就会"以丑为美"，继续在系统上"涂鸦"，引入更多"破窗户"。由此可见及时的修复"破窗户"还兼有"整治歪风邪气"之作用。

在有"破窗户"的项目上增量开发风险很大，特别是当系统业务复杂、架构复杂时，添加一个很小的功能都应谨慎，最好能有完善的单元测试Case做保障。说到单元测试Case，设计起来又谈何容易，特别是对于由C写成的复杂业务系统，C语言本身就缺乏足够理想的单元测试工具，或者说像C这样的语言好似天生就和"单元测试"的概念无法和谐共生。对于复杂的业务单元，我们很难或者无法从纷繁芜杂的业务逻辑中剥离，或者说还是由于代码设计上的"破窗户"导致的不可测性，让"破窗户"得以延续。除非管理层狠下决心，重写系统。现在开始觉得与编写上层复杂业务逻辑相比，能编写一个独立底层库或者实现某种算法算是幸福了，因为你会有一种"可控"的感觉，而不是写完代码心里发虚的很；至于在有"破窗户"的系统上写业务逻辑，那就会又多出另外一种感觉-无奈了。

最近收到客户的一个需求，要求我们将产品的系统配置数据和业务配置数据定期导出备份，以防万一数据库宕掉后可以用来"救火"。产品从起初0.1版本就一直延续着一种"section-key-value"的配置文件方式，同时我们也有可复用的库来完成配置数据的读取，可是在长期的使用过程中我们发现的不少问题，特别是在存储多样化的业务数据的时候，这样的配置方式带来维护上的很大不便。

"section-key-value"这样的配置文件方式或者类似于环境变量似的配置文件方式用来做系统自己的配置可以说既简单又实用，像著名的Apache服务器、版本控制系统svn等都是采用这种方式。在我们产品的初期，那时的业务相对简单，采用这样的一种配置方式还算是合适的。但随着业务复杂度的上升，种类繁多的业务数据的出现，这种配置方式的弊端渐渐显现。

最大的弊端就是"同步"问题。每当我们的产品升级时，我们一般都会先升级数据库的配置，然后再同步文档，最后同步配置文件以及相关读取代码。如果工作量较大，升级工期较紧的时候，常常忽略了将新增或修改的配置同步到配置文件；这样累积到一定时间之后，除了花费大力气去"补"，别无它法。另外一个弊端就是上面提到的那个问题：从数据库导出配置文件始终是那么"别扭"，曾经尝试过使用脚本导出、Java程序导出，但是始终不能让人很满意，挖掘一下深层原因：配置文件和数据库表设计"不搭调"。业务数据千变万化，导致从数据库导出配置文件的逻辑甚是复杂，维护起来十分不便；而且像"section-key-value"这样的结构，数据库中由于没有section的字串，导致这些section必须"写死"在代码中。

不错，我们在寻找替代品，目标锁定在xml。曾经在2005年做的一个项目中尝试过使用xml作为配置数据，取得了很好的效果。记得当时参考Ant的build.xml的配置方式，顺利解决了一个"自动化处理"的配置设计，那应该是部门第一次采用xml做为后台C实现的系统的配置文件。也是自那以后，我感受到了xml的强大描述能力。xml在Java世界可以说占据了大部江山，从DB导出数据到xml可以说轻而易举，这又恰好解决了本篇所提到的"同步"难题。

坐在公司的Bus上，大致想出了如下xml作为配置文件的好处：
1) 与DB表几乎无缝转换，方便导入导出；
2) 作为元语言，其描述能力毋庸置疑；
3) 在Java世界几乎是配置文件的首选或者说是标准也不过分，选择标准的，总会被支持的很好；
4) 诸多开源工具支持对XML的读写甚至支持加密；
5) 文本形式，方便浏览和信息查找(grep or find均可派得上用场)，这也符合Unix编程艺术(TAOUP)作者在书中阐述的一个原则-尽量文本化。
6) DTD或schema验证，自动验证格式是否OK。
… …

当然缺点也是有的：
1) 如果不加密，是明文，保存账户、密码等数据时要小心，当然这也是文本配置的通病；
2) 如果设计不当，会导致"xml地狱"，xml太多也太烦，很多Java世界的产品就有此弊病。

大致在心里估算了一下，读取xml承载的配置与读取传统的配置的代码量没有太大出入，但是如果xml设计的足够精致，后期的维护工作将大为减少。xml配置改造工作看来势在必行了。