近期。同项目组的一位师姐请产假了。由我接手她之前的部分版本号的开发工作。在开发的过程中，我阅读了某个非常古老的版本号的程序代码。心生感触。想在这里啰嗦几句。
该版本号中非常多函数的调用关系都错综复杂，让人读起来非常的费劲。我用例如以下的图来形象化地表示这样的函数之间的调用关系。
箭头的指向为调用关系，如“函数A”调用了“函数B”、“函数C”、“函数D”、“函数E”、“函数F”，以此类推。
当函数之间的调用关系太多时。各个函数就组成了一个复杂的调用网络。非常难将它们之间的关系理清晰。
那么，为什么会出现这么“糟糕”的函数设计呢？原因有下面几点：
第一。最原始版本号的开发者没有做好具体设计，程序是想到哪里就写到哪里。最原始版本号宛如一座大楼的地基，地基没有打好。当然兴许的工作就没那么顺利了。此外。兴许的开发者总喜欢拿之前开发者的程序作为參照。“不好”的前辈仅仅会教出更为“不好”的“徒弟”。
第二，项目组为了赶进度，仅仅要求程序可以实现基本功能。并没有对代码进行严格的同行评审。“赶进度”仅仅会产生糟糕的代码。而假设代码仅仅是一个人说了算。那肯定会留下非常多的问题。
第三，在程序演进的过程中，不同的开发者对同一个版本号的代码进行了改动。假设每一个人都对一个版本号的程序进行改动。因为大家编写代码的习惯都不尽同样，因此会使得程序“越改越差”。
那么，优秀的程序有什么样的要求呢？要求之中的一个就是：函数设计应做到低耦合。高内聚。
也就是说。在不添加代码复杂度的情况下，尽量降低函数之间的调用关系，在本函数实现规定的功能。
“低耦合，高内聚”的函数设计有什么优点呢？优点有下面几点：
第一，便于对程序进行维护。这点非常重要，特别是刚入职的员工，假设他们阅读到了逻辑清晰、编程规范的代码，真的是一种福气。
第二。便于程序版本号的演进。有了好的“模范”，之后对程序的增删改的工作都更加的easy了。
第三。便于不同项目组或产品线之间的沟通交流。优秀的代码应该拿出来，供大家一起学习。
“他山之石，可以攻玉”，仅仅有不断地学习别人好的、成功的经验，自己的能力才可以得到提升。
当然，好的函数设计方法也不是一朝一夕就行掌握的。仅仅要我们坚持学习、不断总结。相信定然会写出优美的、易于阅读和理解的程序来的。
本文转自mfrbuaa博客园博客，原文链接：http://www.cnblogs.com/mfrbuaa/p/5324007.html，如需转载请自行联系原作者