上周日和橱柜公司商量好，下午三点到我的房子量尺，橱柜设计师按时到达，拿着一卷尺开始了测量工作。有过装修经历的人都知道：在装修公司进场之前需要橱柜设计师出一份水电改造图，便于装修公司人员确定水电改造的具体方法。装修公司的施工人员与橱柜设计师之间仅需要一份设计图纸就可以完成水电路改造的沟通，这不由得让我想起这样一个问题："软件开发领域的"图纸"在哪里呢"?

"图纸"是建筑行业的标准的共同语言，它能让设计师与施工者无缝沟通，同时由于建筑图纸的形象性，普通人看了基本也能了解一二，这样普通用户和设计师沟通起来也是很容易的，即使是一个外国设计师设计的图纸，只要使用了标准的图纸符号，中国的施工者也可以完美的将之实现出来，反之中国设计师的作品，外国施工人员也亦然可以实现之。软件行业的人总喜欢拿软件开发与建筑行业做比较，设计模式就是其中最典型的例子。不过这么多年来，软件开发过程仍然无法达到建筑业的那么"精确"，这里的精确不是指过程和进度的精确，而是沟通的"精确"。

软件开发领域的"报怨声"已经持续了几十年了，需求分析人员无法获取用户的准确需求、系统设计人员无法将自己的全部设计思想很好的传达给编程实现人员，人们都在抱怨：缺少一种"共同语言"，能让他们之间"无缝的沟通"。软件业的大师们绞尽脑汁、费尽心思、提出了多种沟通语言，以试图解决这个问题。这里面最著名的莫过于由OMG组织于20世纪末推出的"统一建模语言(UML)"了，顾名思义，UML试图统一软件开发领域所有过程阶段的"沟通标准"，需求阶段有Use Case图；设计阶段有组件图、类图；部署阶段有部署图，另外还有序列图、状态图、活动图作为辅助。UML到目前为止也从1.0发展到了2.0版本，但其实际应用情况如何呢？乐观点说是：没有"图纸"在建筑领域应用的那么广；如果从我了解的和接触的实际情况来看，UML已经过了其高峰期，开始变得"不瘟不火"。

程序员多数喜欢简单化、个性化和形象化的表达思想，一块白板，无拘无束。虽然UML在形象化上做的还不错，但是却始终无法打动程序员的心扉。从另一个事实来讲，图纸是建筑行业的门槛或者说是基础，而与之对应，代码才是软件行业的门槛。这样一来似乎代码才应该是一种共同的语言，在"敏捷软件开发"的附录中就有这样一篇文章："源代码即设计"。那是否说："代码"就是"软件业的图纸"呢？"代码"在设计开发人员之间可以说是基本无缝的，但是对于普通客户而言，代码似乎太专业了。其实在建筑行业"图纸"也多在设计师和设计师、设计师与施工人员之间做沟通之用，大项目中少有客户与设计师沟通时使用"图纸"，多数会用外观效果图。这样一来似乎软件开发领域的"代码"与建筑业"图纸"的概念达到了一定的一致性。"代码"作为沟通媒介的前提是：代码和设计的统一。为了达到这一目的，需要代码结构清晰，可读性，可沟通性要好，这也势必需要实现人员提高编码技艺。都说编程是一门艺术，从这里来看，名符其实。如果承认"代码"这一地位，那么实际上是确定了一个方向，以后向这个方向努力就是了，众所周知的"敏捷"在这个方向上做出了努力。

上面也已经说过，"代码"过于专业，并不能作为"统一沟通媒介"来统一整个软件开发过程，看来我们只能继续期待头脑中理想的"图纸"的出现了，也许它会诞生于将来的一个突破性的"发明"或"发现“；也可能它将是一个永远的"梦"。

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

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

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

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

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