[记录]编程思想（一）：提供"mechanism"还是"policy"

　　程序员不是一天练成的，但是遵循一些编程思想，可以使我们少走很多弯路。

　　今天看《Linux Device Drivers》，在第一章中提到了编程思想。我做过很多开发项目，由于不是在大团队开发的公司，例如华为，某些外企，很多项目人手很少，基本上需要独立负责，回想起来，我在系统设计结构方面确实有很大的进步。不过一直没有认真的总结。当时看Thinking in JAVA，前言写得太好了，就是涉及编程思想，可以具体讲了什么，现在却也想不起来了。所以我想将看到的或者想到的，记录下来。

　　我记得前年有个大项目，用JAVA提供的应用，在性能方面一直无法突破，做了N多的尝试和实验，什么线程分拆等等都没有用，最后我认为是JAVA VM的限制，只能绕开解决。我使用了多进程的方式，当然没有进程里面也是多线程的，模拟了多个板卡工作方式，进程可以在本机或者其他机器上运行，虽然JAVA VM对单个进程有限制，但是多个进程，效率可以线性增长。采用模块的方式来修改我的系统，一开始觉得工作量会很大但是真正组织起来，发现还可以。由于里面功能模块编写得完整和独立，只是换个架构，换个马甲罢了。

　　我觉得测试对于开发人员是很重要的，虽然有时公司可能有专门的测试人员，但是开发人员自己要给自己把关，编写测试工具是非常重要的。测试工具虽然只是辅助性质，例如我写的一个SIP的流程小程序，可能根据脚本来设置流程方式，以及增加里面SIP消息的参数header，一开始只是缺少调测编译，后来这个程序成了模拟各种环境，包括异常流程一个很重要的调测工具。还有一个我自己写的性能测试的小程序，后来有一个项目很紧急，合作小组搞了很久，在大容量上面真是越急越出问题，解决一个问题，发现一个问题。后来没有办法，通宵了几天，我以测试小程序为主体顶了上去，最后成了一个大程序。

　　回归正题，今天话题：提供"mechanism"还是"policy"。

　　这是系统设计包括OS的关键。"mechanism"解决的问题是：有什么功能提供，而"policy"解决的问题是：这些功能如何使用。这两个部分至少应该放在程序的不同位置，或者放置在不同的程序模块中。这样软件包就容易开发并且能适合特定的需求。我们也可以这么说将功能提供和实际的（特定的）应用区分开来。对于功能部分要做到policy-free。

　　还有一种情况，我们的程序需要通过宏定义#ifdef xxxx，来屏蔽OS的差异。这个差异包括linux和windows的通用代码，也包括某个OS不同版本之间的差异。和这些相关的代码可以视为程序中的low-level，而high-level部分的代码通过调用low-level的函数，而无须考虑版本或者平台之间差异。在编写代码的时候，我们应该区分组织他们，使得程序不仅易懂，容易维护，具有更好伸缩性和适应性。

相关链接：
我的与编程思想相关的文章