关于 Unix 编程艺术的随笔

winston

我是 Unix 编程艺术的追随者，因为它将复杂的问题变简单了，让程序员在‘偷懒’中创新，以下我谈谈个人对如何实际操作 Unix 编程艺术 的一些想法：

一、自上而下的思考：
首先，我们追求的是“拼装式”开发，因为这种开发高效且可靠，而且我们只需要增加新模块而不需要考虑修改旧模块，就可以实现支持新功能兼容旧功能，光想想就能让有一年以上工作经验的程序员笑开嘴了:D。

其次，为了能在大多数项目中实现上面这种“拼装式”开发，就得要求每个组成模块都是可靠的，而且有着统一的接口，这统一的接口可以如微软的互动接口（我问：能不能做啊。你答：能做。Ok，活交给你了，拿到活的是排在队伍前者的），也可以是 Unix 传统的管道，一切信息皆由字节流进流出。

此时，你可能就恍然大悟道：原来 Linus Torvalds 选择 Unix 做为开源操作系统 linux 的原型是这样啊！

呵呵，是的，Unix 的编程艺术是让模块制定标准，调用者来选择自己可以接受的模块来实现自己的流程。
微软则是一如既往的我定标准，你来实现，典型代表如：COM 。

微软的这种作法可以让互相从未通过气的各家做的，拿到一起必然可用(前提是按标准做的)，但是开发者就不能我的代码我作主了，上来你就得先学习微软的玩法，英语不好的、想加快进度的，不整来几本微软出版社出的书学习学习，你做出的模块就听不懂微软的语言，无法与微派模块沟通，结果就是没活干，靠边站。

而 Unix 的管道则是天然统一接口，开发者根据自己的需要做完模块，说明字节数的组成格式，然后连模块（大多数有源代码）及字节数格式说明规范一起上传到网上，与大家分享，想要用我的模块就要按我的规矩办。

你说  Linus Torvalds 不用这种开发式来拉人入伙搞开源，怎么可能搞到今天如此之大呢？

这也给我们一个启示：脑力工作者是相当‘随心所欲’的，这既是创新的源泉，也是豆腐渣工程的伏笔！

所以说只有从两大派别的共同特点：都有标准接口　入手方能打蛇打七寸。

最后，我们就要思考这个标准接口了，因为它是团队合作的核心，也是产品是否能可持续发展的关键。

我们往往为了某个项目而临时制定了一个可以解决暂时问题的标准，即当前客户要实现的功能所需哪些数据信息开始倒推，倒推的过程中产生各个所要数据信息的关键函数就成了模块或团结了其它函数后形成了模块，整个倒推的过程完成了，整个产品的框架结构也就形成了。

从生物学的角度上讲，猴子、狒狒、猩猩，再近似人，也不可能干出人事来，因为它们的骨架已经决定了它们的脑容积和生活方式。

同理，一款产品如果只是针对一个项目倒推出来的那么它最多只是适用于这一个项目的此时此刻，而且开发的过程中程序员也会倍感各个模块沟通困难，尤当客户的需求在中后期发生了一些变化时，更是让程序员痛苦，只能强改程序流程，大量的全局变量涌出，利用全局指针做‘时空穿梭’比比皆是，目地就只有一个让这痛苦的工作在自己手里结束，侥幸的想下次不一定是自己改，管他呢。

二、自下而上的思考：
1.当我们每完成一个新硬件、一个新算法、一个新...的操作代码后，是不是应该考虑把它封装成纯 C 语言(C 语言通用性好、移植性好)的基本模块(以Linux为例，可编译成动态库且静态库为准)呢？

因为这样的模块会随硬件的消失而消失、会随着文件格式的淘汰而淘汰、会随着...，新硬件、新文件格式，就要生成新模块，不要让它干太多事，太多的分支流程绕不死 CPU 前，就先把程序员逼疯了，为了别人的健康和为了自己少一些被咀咒，请少一些分支，多一些注释吧！

合格的模块 = { 详实的设计文档（及参考文档） + 良好编程风格  + 准确到位的注释  };
注：
没有详实的设计文档（及参考文档），如日后很多硬件的操作码就不知其原由了，再无注释，就更不知其所云，再命名排版一团糟，....(接过此类代码的同仁们，我就不说了，你懂的)。

此类模块采用的一定是标准框架结构，即1)初始化函数，2)反初始化函数，3)各功能函数；
注：初始化函数一定要采用微软的传统做法，要支持被询问，方可在后期支持多硬件或多文件格式等。

2.有了基本的操作模块，我们就可以考虑如何组织业务逻辑模块了，这种模块就是我们要：
先回顾该业务逻辑功能的今生前世及可能进化的方向和原由、
再聚集体智慧(头脑风暴和更多眼球找错)认真考虑、严格把关，
之后我们就发现原来该业务逻辑模块的对外接口原来是这样的啊！

业务逻辑模块最好是能像 Unix 那样做成一个个可执行程序（动态库为次之），
看似多，实际上有了文档说明，对它们的调用将无比灵活。

合格的模块 = { 详实的设计文档（及参考文档） + 良好编程风格  + 准确到位的注释  };
注：
没有详实的设计文档（及参考文档），如日后很多业务逻辑就不知其来龙去脉了，再无注释，就更不知其所以然，再命名排版一团糟，....(接过此类代码的同仁们，我就不说了，你懂的)。

3.最后，终于回到了我们梦想的“拼装式”开发上来了，先不要捋起衣袖就干，我们虽然了基本模块和业务逻辑模块，但是如何组织和传递程序运行时的动态数据信息，正是整个产品的框架设计的核心，也正像是物理世界各种物质如何聚集它们的组成分子一样。

如何组织程序运行时的动态数据信息，就要分析客户项目需要哪些功能，以往项目中如何实现，同行产品如何实现，孰优孰劣还是兼而有之还是反思改进，这些功能由哪些基本模块或业务逻辑模块产生和使用，这些问题想清楚了组织结构图就在文档中浮出来了，然后转化成代码即可。

如何传递程序运行时的动态数据信息，就要看产品最终运行的平台了，类 Unix 操作系统平台，自然可以考虑管道、函数调用、socket 等，进程内的数据信息传递，自然不要考虑功能的独立使用性了，而且也无法实现本地与分布式的自适应了（管道这种进程外传递也无法实现，但可以实现独立使用性）。