《Pragmatic Programmer》读后感（一）：为何会有如此多的破窗户？

终于买到了这个享誉盛名的《程序员修炼之道》。自从第一次见到这本书的电子版时并草草浏览了其中一些章节之后，一直都盼望着能够买到这本书并好好阅读一番。而今，终于可以开始好好品尝了，心里自然别有一番滋味。

这几天，初步看完成了第一章“注重实效的哲学”，看完之后，“破窗户”这个名词一直在脑海中打转。仔细回想耳闻目睹或亲身经历的开发历程，原来“破窗户”竟是如此普遍地存在着。

前不久，一个偶然的机会，目睹了一个同事写的代码。一个方法竟然有1000多行，更突出的是，在这个大方法中，所要实现的功能或所要完成的职责竟是多不胜数，方法之间的相互调用、UI处理逻辑与业务处理逻辑的相互渗透等等，简直可以说是鱼龙混杂了。于是，笔者友好地向这位同事提出了一些改进的建议，而同事却回答说，这部分所要实现大功能的代码原本是从其他系统移植过来的，为了方便，与之相关的新处理逻辑的增加或是修改都直接在上面处理了；虽然自己也不是很赞同现有的处理方式或代码风格，但限于现有的代码结构，所以最终也就照着前人之路继续开发了。

其实，笔者打从心底不赞同这位同事的说法，至少这样的做法不是一个程序员所应该做的。但同时也知道这位同事的无奈，因此这建议也就罢了。然而，在目睹过这一情形之后，笔者在每每写代码的时候都会不自觉地想起这种情形，写代码自然也更加不敢肆意妄为了。

今天想来，这种情形真真就是一个大大的“破窗户”，这个“破窗户”是谁造成的并不是重点，重点在于后续开发者或维护者一而再再而三地容忍这些“破窗户”的存在，才造成了后面不可收拾的糟糕局面。

再回过头来看看自己编写的代码，也难免会出现一些“破窗户”，有些可能已经被发觉，而有些则可能隐藏了许久都未曾被发觉。但至少笔者在努力做这样一件事，一旦发现“破窗户”，将立即着手进行修补改造工作，而若来不及修补改造，则会对该“破窗户”加上标记，以待日后修补改造。

很多时候，“破窗户”都是不经意间造成的，或是工作的疏忽，或是经验的不足，等等。但正如书中所说的那样，不要容忍“破窗户”。只有这样，才能编写出更加清晰、更加整洁、更加优美的代码。