模块化编码——unix编程艺术学习笔记

模块性体现在良好的代码中，但首先来自良好的设计。下面是问题清单：

1、 有多少全局变量？全局变量时模块化的毒药，很容易使各个模块轻率，混乱的泄露信息。

2、 单个模块的大小是否在hatton的“最佳范围内”（物理行在400~800间）？如果回答是不，很多都超过的话，就可能产生长期的维护问题。

3、 模块内单个函数是不是太大了？这是一个内部复杂性的问题，如果不能用一句话来描述一下一个函数与其调用程序之间的约定，这个函数要么太大，要么职责不明确，非常可能两者兼而有之。

4、 模块是否有设计良好的API——即可以作为单元向其他人描述的函数调用集合和数据结构集，并且每一个单元都封装了某一层次的函数，不受其他代码的影响？好的API应该定义清除，不用看具体如何实现就能够理解的。一个经典的测试方法：通过电话向另外一个程序员描述，如果描述不清楚，可能是API设计太复杂，太糟糕了。

5、 API的入口点（什么是入口点，应该就是模块对外的接口）是否超过7个？有没有那个类有七个以上的方法？数据结构的成员是否超过七个？（注意，这里都是以七为分界线，因为人同时能够处理的信息最多只有七个）。

6、 整个项目中每个模块的入口点是如何分布的？是不是不均匀？有很多入口点的模块真的需要这么多的入口点吗？模块的复杂度往往和入口点数量的平方成正比。

可以结合为透明性和可显性而编码——UNIX编程艺术学习笔记一起学习更加有启发性。