走不出的“通用”怪圈－－coding or configing

最近，自己积累的代码库中一些通用代码、通用类开始多起来，但随之而来的，却是一个又一个配置文件的出现，接着，管理这些配置文件又成了一个难题。

或许是自己刚刚摆脱懵懂，挥汗之际才真正体会到“配置污染”这个词的含义。曾经构想过的“接口－引擎－数据” 式开发似乎也走入了一个迷阵中。也许真是像人说的那样，你要coding还是configing？

一个任务，做过一次，便不想再做第二次，因为程序员的天性就是复用，目标就是效率，一次又一次的CPP（Copy、Paste、Print）是会被过来人耻笑为“迂腐”的。那么既然是复用，整个模块就会有专用和通用的地方，通用的做成引擎，而专用的做成config，OK，一切似乎都是比较完美的。

但当模块被复用的越来越多时，你需要考虑的地方会越来越多，那么你的config机制会越来越庞大，于是大量的assembly或者jar包出现了，成千上万的ocx带着各自的config file或者document出现了。

当你真正需要某个模块时，却被它庞杂的config系统震慑了，从哪里下手？自主开发适合自己的专用模块还是使用配置和复杂的通用模块？开发时间和学习时间到底哪个多点？

当然，这个矛盾是程序员永远躲不开的权衡，但愿我们的开发在摆脱知识冗余之后，不会走上另一个极端－－“配置污染”