沉思录二：以unix哲学基础的架构设计

面对一个架构设计繁复的linux服务器端应用，难于维护的局面，如何破局？经过一段时间反思后，我找到了《unix编程艺术》一书。看看其中unix哲学基础章节如何说的。

一. unix哲学基础

1 模块原则：使用简洁的接口拼合简单的部件
2 清晰原则: 清晰胜于机巧
3 组合原则：设计时考虑拼接组合
4 分离原则: 策略同机制分离，接口同引擎分离
5 简洁原则：设计要简洁，复杂度能低则低
6 吝啬原则: 除非确无它法，不要编写庞大的程序
7 透明性原则：设计要可见，以便审查和调试
8 健壮原则: 健壮源于透明与简洁
9 表示原则: 把知识叠入数据以求逻辑质朴而健壮
10 通俗原则：接口设计避免标新立异
11 缄默原则：如果一个程序没什么好说的，就保持沉默
12 补救原则: 出现异常时，马上退出并给出足量错误信息
13 经济原则: 宁花机器一分，不花程序员一秒
14 生成原则: 避免手工hack，尽量编写程序去生成程序
15 优化原则: 雕琢前先得有原型，跑之前先学会走
16 多样原则:决不相信所谓“不二法门”的断言
17 扩展原则: 设计着眼未来，未来总比预想快

在这个繁复的项目里，几乎没有遵守以上所有原则。是的，一条都没有遵守！！

二. 结合实际

书本之言是纸上谈兵，如何和实际项目结合？以下问题值得着重关注。
1. 架构设计要结合实际项目资源
项目资源包括项目里可用的人力工时，必要的配套硬件软件资源等等。如果架构设计宏大，但是中短期人手不够，在解决从0到1的过程都没有足够的人手和软硬件资源，就要考虑适当缩减设计规模。
当然，设计架构缩小规模，确立保证主要功能的实现，这并不是损失扩展性和健壮性为代价的。而是减少部分初期不需要或不重要的功能，去适配相对缺失的各种项目资源。
实际情况：设计宏大而不顾及匮乏的项目资源，实现的开发人员经常加班，在疲劳和催促中，不再顾及质量和弹性的实现代码。

2. 模块接口设计繁复
项目中各个模块的之间的接口设计应该简洁高效，使用的机制应该易于理解和实现。
实际情况：模块之间的接口过于繁复，选择的实现机制是所有可用的方法中最复杂的。实现项目的人对所用的机制理解本身就存在误解和缺陷。

3. 违反透明性原则
早期的项目基本需求一直模糊不清，架构设计文档缺失，很多原创开发者流失，导致到处都是谜团一样架构设计和代码实现。

4. 没有预留测试接口
检修口的预留是很重要的。在一个复杂的系统里，如果有一个地方，在揭开盖子后，可以直接观察系统内部运行的状态，或者插入检测的仪器，就能输出内部的运行状态；
比较致命的事，在模块的接口和连接处，根本没有预留或规划测试用例。更准确地描述，是很难写测试用例，一方面是搞不清流经接口的数据格式和边界，另一方面也没有思考如何运行测试用例。

5. 扩展的太早太早
很多的设计偏向便于扩展，但很多是提前就开始扩展。一定要考虑便于扩展没有错，但是不顾实际项目需要，一开始就设计和实现出几年后才可能需要的扩展。

6. 策略和机制混淆不分
没有找到最优的机制和策略，但是更致命的是，机制和策略代码实现混杂在一起，单独修改升级机制或策略，都是工作量极大的重写。
一个很明显的例子。读取XML文件里的配置项。没有设计实现一个业务无关的读取XML节点的函数，同时把业务逻辑和读取XML节点的实现全部硬编码在一起，再加入不同条件下使用不同的配置项的代码。

三. 设计是什么

1. 架构设计可实现
表面上天马行空，好大喜功的架构设计，如果不能落地，没有任何意义。有一次听到一个工程师说，架构设计就是写文档。设计文档是必须有的，但是里面的设计必须是能实现的。
设计能实现就必须要结合实际情况，设计师应该每项设计都自己做过类似的代码实现。写出设计文档如果不能指导实际工作，和废纸无异。

2. 架构设计是妥协
软件架构设要考虑能实现，就必然考虑到目前的项目资源，受限于资源，必然砍掉或暂停短期不用的，必然选择把握最大的简洁的设计方法。架构设计更多的时候，其实是在规划设想和现实之间的妥协。

3. 架构设计是草图
类比建筑设计，数字电路原理图，软件架构设计有极大的相似性。设计后的代码开发都是按照架构设计图展开实现的，必须充分考虑可能的数据格式，算法，业务流程，检修接口等等。
既然是设计图，就需要跟随实际的变化做适当修改，既要指导实践，也要保证和实际情况同步。在项目后期，拿出的设计文档，要和实现的代码充分契合。