有关C语言模块化实现的探讨(1)

本文节选自云风的博客上近日的两篇文章：《好的设计》和《C 语言对模块化支持的欠缺》。

由于最近几年用的主要开发语言是 C 和 lua 。那么也打算以此为基础写。假定读者至少有不错的 C 语言基础了。我真正想谈的是，如何把一个软件很好的构建起来。到底需要做些什么。（从实现层面看）怎样才是好的软件。

那么有一个重点问题，也是老问题，怎样才是好的设计。

好的设计，必然是容易实现的。它可以很精巧，但不能难以理解。

太阳底下无新鲜事。软件行业已经发展了这么多年，你想到的东西，肯定有人都想到过了。

每个软件也都有它的生命期，我们只要在它的生命期内完成它的使命就行了。软件往往需要尽快的投入使用，然后在使用中演化。这个演化最大可能并不依靠你一个人的力量去推动。随着参与的人增加，人和人（指开发人员）的共性就会减少。每个人都看得懂可以充分接受，软件才不容易向坏的方面演化。

我们常常谈模块化，谈高内聚，低耦合。

本质上，就是如何管理复杂度。如何把一件很难的事情（开发一个软件），分解成小问题，分而治之。

这些小问题之间的千丝万缕的联系，是设计人员面临的最大难题。

有些原则听起来不错，但是坚持起来很难。

比如，让模块的输入输出没有副作用。你能让你的模块每个输入对对应着唯一输出吗？

又比如，让模块层次化。如果 A 模块依赖 B 模块，B 模块依赖 C 模块。一旦出现这个状态，你能保证 A 模块绝对和 C 模块隔绝吗？更有甚者，让三个模块循环依赖这种更糟糕的事情也并不鲜见。

抽象是个好东西。但借助不断的抽象，问题不断的包起来，演化成新的巨无霸，显然会让事情更糟。虽然最终可能真的能像搭积木一样去组装软件了。或是雇佣更多的程序员填表单一样的工作，相互不需要对方在做什么。但是，软件性能却下降到了不可以忍受的地步。bug 也隐藏的更久，更不可收拾。

好的设计，必须对问题有足够清晰的理解。有如庖丁解牛一般，把整个问题划开，在最薄弱的地方分离。其实，做到这点，也就够了。

解决这些问题，其实跟语言无关。语言之争是没有多大意义的。如开头所说，把设计做好，模块之间的关系，用足够简单的方式就能描述清楚了，大部分流行的开发语言都能做到。

用 C 来实作，而没有用它的近亲 C++ ，也是为了避免狭隘的争议：我们该用这个特性吗？该用那个特性吗？这个形式做是不是好点？那样会不会有更好的性能？

所谓开发效率，对于个人来说，语言之不同，是会有很大差异。但是那是实现层面的差异。对于完成设计，这个过程，效率和所用语言无关。

实现的阶段，程序员可不可以开心的放心的去完成那些接口，这就是衡量设计好不好的指标了。这个时候，一个高开发效率的语言有优势（更少的代码量），一个容易掌握的语言也有优势（可以让更多的人参于而少犯错误）。

对于我的团队，我会更乐于采用一种让实现人员更轻松的方式。不用理会太多的语言细节，不用在投入开发前学习更多的概念（尤其是这个项目独有的），不用特别严格的 code review 也可以允许大家提交新的代码，切不至于轻易的引入 bug 。

我相信，软件做到后面，设计人员不需要亲自写太多代码。虽然我现在每天还是大量的写，也并不觉得枯燥。

事必恭亲是不好，但并不是说，你给实现人员足够信任就可以放手的。真正让你放手的只能是，你做出了好的设计，无论是谁，他也写不坏它。这时，是你乐意自己写，还是多找几个同学帮忙写，已经不重要了。