架构设计的检查表

像《C++沉思录》中的“类的设计者审查表”一样，写一个“程序架构设计的检查表”。以后做一个新的程序或者维护一个程序的时候，拿出来对比检查一下。看哪些地方可以改进。都是多年程序设计的总结，虽然框框很大，没有具体细化，但确实是经验和教训的总结。

 

程序设计应该达到下面的目标：

1.全局/局部效率高
2.所占用资源小
3.可维护性／明晰性    
4.正确性
5.可测试性（利于进行单元测试或者白盒测试）
6.一致性（除了本身就是随机性的问题外，相同的条件应该产生的输出）
7.可扩展性（加功能方便，随着用户增加，扩展机器方便）
8.易于监控

 

这上面这些要求，有些在实现中往往是有冲突的，比如局部效率高和可维护性，一般效率越高，往往编码会更晦涩，可维护性就差些，当然也不是绝对。

 

 

实现途径：

1. 大道至简
重剑无锋，大道至简。设计的最基本哲学。能简单就不要麻烦。

 

2. 一切服务皆可被灵活路由。
可扩展性的关键。参见日志上的另一篇文章《互联网设计之关键：一切服务皆可路由 》。

 

3. 最好是无状态设计。如果有状态，状态要尽量集中在一起，其他需要使用状态的服务通过接口来更改和查询。
（1）好处是维护状态的代价小，比如为了容灾，添加备份机。如果状态集中在一台机器上，那么只需要添加一台机器即可。否则，每个保存有状态的机器，都需要加备份机。
（2）方便状态监控。只需要小心设计编码这一部分程序即可。
（3）避免状态不一致引起的bug。分散的状态容易引起状态机转换的bug。

 

4. 主要功能流程和辅助功能流程分开
保证主要功能流程的容灾备份。
辅助功能如果出现网络故障或机器故障，可以暂时缺失。做到柔性可用。

 

5.封装变化
变化的数据和接口做好封装。一旦变化，只需要修改接口模块。避免大幅度改动。

 

6.模块接口数据一定带版本号
防止变动带来的兼容性处理。

 

7.服务功能的划分要耦合小
实现可维护性和可测试性的关键。往往也是可扩展性的要求。
而且功能的正确划分，是实现并行分布式计算的基础。

 

8.算法的选择
算法的效率的关键。终级武器。算法封装好，以便发现更好算法的时候进行替换。也方便对比测试各种算法的优劣。

 

9.设计模式的灵活应用
说起来容易做起来难。关键是要对业务比较熟悉，能够尽量预测将来的变化。

个人觉得，合理的模块划分，比设计模式的应用更重要。合理的模块化分，更容易限制变动影响的范围。

 

 

10.永远不要相信外部的输入数据
编码的格式，外部数据的特殊字符，乱码等等。尽可能早的处理掉，最好在前台或者接入层处理掉，最迟也要在进入核心和主要处理流程之前处理掉。绝不要影响主要流程和核心功能，或者增加这部分功能的处理负担。

 

11.跨平台程序设计
真想做到跨平台的话，就必须同时开发。所谓的移植只会令产品在第二平台上蹩脚不堪。

 

12. Review代码

Review代码真的很重要。提高程序质量的关键。

 

13.代码的组织

做一个项目，先把代码库的目录结构定义好。整个项目的维护性才能更好。

编码的规范也要提前制定好。

写好文档规划好每一个目录下应该存放什么功能的文件，以便大家都能放文件放在正确的位置。
公用的代码提取出来。放在诸如comm或者tools之类的目录下。

 

14.不要太相信第三方库

开源的库，谨慎使用。

(1)引发安全问题

(2)第三方库引入的Bug

(3)软件变得臃肿，维护性差。你还得关注你使用的第三方库的升级，尤其是由于安全问题引起的升级。

 

15.日志的规划
把日志规范好，以便后面分析跟踪bug。
日志应该包含文件名，函数名，行数，时间戳和进程（线程）ID。日志的格式最好能规范好。
日志文件分文件存储（按时间，大小，进程）。
最好建立专门的日志模块供大家调用。日志分等级，个人觉得日志除了一般的DEBUG, ERROR， WARNING之类的等级外，最好添加一个LOCALUSER等级。
只需要编程者自己一个人看到的日志，用这个LOCALUSER等级。
错误返回进行分类（可以结合服务器序号），提供根据错误ID，最好有全局的错误ID编号。谨慎使用异常。

16.分而治之
大化小，小化了。将大问题拆开。
二分法是解决问题的“圣水”，包治百病。

 

17.谨慎引入新技术
不建议在一个项目中引入太多项目组成员都不太熟悉新技术，避免太大的风险。使用之前一定要先熟悉测试，做好风险预估。