破窗户到底要不要容忍？

　　《程序员修炼之道》两位作者在书中很早就谈到：不要容忍破窗户。我不知道外国程序员的代码写得如何，但是，我觉得，在中国做程序员，很有可能你是要容忍的，也许你并不情愿，不管这个破窗户是你写的还是别人写的。

　　之前的项目中有一个最重要也是经常需要更改的模块——POS机的交易模块。因为这方面客户的需求往往是要从这个模块中来更改的，于是，程序员们来来往往几个人改了又改了，到最后这个模块就变成这样一个模样了：有2000行的C函数，有漫天飞舞的变量，有满街乱闯的指针，有不同的命名规范，有泥团似的代码逻辑块。

　　这个时候，你敢去重构吗？一个模块一万多行，你有时间，有精力，有耐心去重构吗？我实话说，我不敢冒这个险去踩地雷阵。在此之前我尝试过去重构一个两千多行的函数，这个函数单单变量就上百个，过程中我越发感觉到自己是在做一件极其困难的事情，抽象出来的函数需要传递的参数太多太复杂，各函数之间因为全局变量等原因使得耦合性非常强，到最后我放弃了。所以，我感觉能做就是在这个基础上，根据自己需要，把一些独立的逻辑模块抽象出来，构成一些新的函数，代码重复就暂且让它重复吧，先把DRY抛到脑后，用新抽象出来的函数来为自己服务。在我看来，也许这是目前比较靠谱的做法。

　　但是我很快就碰到一个头疼的问题了。由于代码许多重复了，而命名又是如此之接近，导致我难以弄清哪些是最原先的函数，哪些是后来别人抽象出来过的，而我又应该用哪些为新功能服务。个别函数命名只是调换了主谓语，个别函数后面带了个数字“2”，个别函数后面加了主机名来识别。总之，不管你如何避开，总有一些让你头疼的。你勉强完成了任务，但是，过程足以让你痛苦。每次你需要用到别人的东西，你总是小心翼翼地查看这东西到底是不是自己真正需要的，其中到底有没有地方需要更改。如果你运气足够好，也许根本不用更改；如果你运气太差，需要更改的东西太多，你自己又得重新写一个类似的函数，改动其中你需要更改的地方，然后再想破脑经构造一个新的函数名。到最后，你已经和之前的人一样了，恭喜你，你们的项目中可能又多了一种命名规范，可能又多了一些重复代码。

　　我现在是糊涂了：如此难以两全其美，这样的情况到底要如何处理才能真正妥当？