面对'破窗户'的无奈
每天早晨都是坐公司的班车上班的,从家到公司大约需要40分钟,这段时间不短也不长。为了打发时间,也曾经想过要充分利用这段时间,我选择过听音乐、看书。但音乐听时间长了就听烦了;在车上看书时间长了还有些头晕,所以多数时间我还是选择"思考"。"思考"的同时,眼睛也一直在"欣赏"车窗外的风景。今天窗外一处新楼盘门市的两个破碎的窗户让我的"思考"有了方向。
建筑物上的几扇"破窗户",很多人即使注意了,也会不以为然。但是对于看过 Andrew Hunt 和David Thomas合著的"程序员修炼之道"一书的程序员们也许都会"见景生情",因为在工作中身为程序员的我们时常(甚至总是)和"破窗户"打交道。
万事万物都是有其共同的规律的:建筑物上的破窗户、牙齿上的"小洞"、软件中的低劣设计、糟糕代码的等等,在其出现的初期也许并未显现出问题,但是如果你没有及时修复,建筑物上也许会出现更多破窗户、被丢了很多垃圾、被胡乱的信手涂鸦;牙齿上的洞洞越来越大,周围的牙齿也受到牵连,开始出现"小洞";软件中低劣的设计风格被继承、糟糕的代码被复制并被散布到系统的方方面面,以至于到最后无法控制,或者是花费很大力气来修复。
面对"破窗户",常有这样几类情形:
1) 无法识别"破窗户";
2) 识别出"破窗户",但不愿修复;
3) 识别出"破窗户",有修复意愿,但"破窗户"难于修复,或者修复成本太高,或外部因素(时间、人员、成本)导致资源不足以修复这些"破窗户";
4) 遇到"破窗户",立即修复。
前两种情况,一个是水平问题;另一个就是职业素养问题了,这里不多说;我们常遇到的情况往往是最后两种,如果是最后一种,其实你是幸运的,多数这种情形下你从事的一个新的系统或者项目,没有太多的遗留代码,一切都在自己的控制之下,通过重构可以达到修复"破窗户"的目的;但是如果是第三种情况,那往往是最让人痛苦的-自己无法控制,即使有渴望有热情有能力去修复那些"破窗户",但迫于系统庞大,业务复杂,时间有限而不敢轻易出手,更让人痛心的是,系统中"破窗户"的设计和代码渐渐传染给新人,新人在维护系统时就会"以丑为美",继续在系统上"涂鸦",引入更多"破窗户"。由此可见及时的修复"破窗户"还兼有"整治歪风邪气"之作用。
在有"破窗户"的项目上增量开发风险很大,特别是当系统业务复杂、架构复杂时,添加一个很小的功能都应谨慎,最好能有完善的单元测试Case做保障。说到单元测试Case,设计起来又谈何容易,特别是对于由C写成的复杂业务系统,C语言本身就缺乏足够理想的单元测试工具,或者说像C这样的语言好似天生就和"单元测试"的概念无法和谐共生。对于复杂的业务单元,我们很难或者无法从纷繁芜杂的业务逻辑中剥离,或者说还是由于代码设计上的"破窗户"导致的不可测性,让"破窗户"得以延续。除非管理层狠下决心,重写系统。现在开始觉得与编写上层复杂业务逻辑相比,能编写一个独立底层库或者实现某种算法算是幸福了,因为你会有一种"可控"的感觉,而不是写完代码心里发虚的很;至于在有"破窗户"的系统上写业务逻辑,那就会又多出另外一种感觉-无奈了。
评论