关于编写高可靠性的软件（系统）的一些思考

关于编写高可靠性的软件（系统）的一些思考及今年决定要改善的地方。

 

1. 源代码与源文件

　　1) 总的原则是结构清晰，易于理解和查找。不管是源代码的变量，函数，模块，还是文件，目录，都应该是经过精心组织的。因为很难说怎样的目录结构和代码是最好的，所以精心组织代码和文件的结构以适应不同的应用才是上策。

怎么写好的代码已经有好多书在介绍了，例如《Write Clean Code》，《C、C++高质量编程》，《代码大全》。关于目录结构的组织还是多看看出色的开源项目学习学习会比较好。

　　2) 包含关系简单。目前我们的代码的一个非常严重的问题是包含关系的复杂程度。我设想的包含原则应该是这样的。

　　　 a. 系统中会有基本头文件，例如，标准库头文件，基本类型头文件等。

　　　 b. 各个模块对外公布的头文件应该只包含基本头文件。

　　　 c. 如果必要各模块可以提供供模块内部使用的公共头文件。

 

2. 测试

　　这里讲的是开发人员进行的测试，特别是指unit test。我们目前在unit test这方面做的比较差。应该提供自动化测试的方法，例如cppunit这样的工具。但在现阶段还不行，到我们引用C++后是可以考虑实施的。今年的重点是针对新加功能，要求能test case列表和测试结果，如果有改动需要重跑相关的unit test case。

 

3. 调试

　　目前我们的系统主要提供Config命令，Trace和Exception Log来进行调试。从目前情况来看，这几部分都需要改善。

　　Config部分希望能增加一些MAF状态信息的命令（类似于Condat的common config这样的命令）

　　Trace部分希望能改善丢trace，level不好控制的问题。

　　Exception Log还要再看一下，我们需要在Exception里输出一些什么样的信息对分析问题有帮助。

　　一个最头疼的问题是如何让系统在hang住的时候自己当掉，以方便程序发现问题的根本原因。

 

4. 动态分析

　　记录一些我们需要关心的系统的峰值对我们调整系统的参数是非常重要的。所以我们应该更多的考虑在不影响系统的情况下多加一些记录系统工作情况的记录。例如，系统中使用Memroy的情况，stack使用的情况。

 

5. 静态分析

　　我们的系统越来越复杂了随着新功能的不断加入，系统出现问题的地方也越来越多了。特别是进程间是否会死锁这样的问题，光靠阅读代码已经很难分析了。是不是需要引入一些静态代码分析的工具？

 

6. 文档
 　　这是老大难问题。我们把文档分为三种：系统架构文档，设计文档和用户手册。
　　用户手册不用讲是一定要的，而且也是必须和代码同步的。但是由于我们是inhouse的产品所以大家普遍对用户手册不重视，今年的工作重点就是要review我们的用户手册。让我们的用户可以在用户手册的指导下就能完成自己的工作，而不用老是跑过来问我们的程序员。
　　系统架构文档，这部分文档问题不高。因为架构更新的频率不是很高，所以同步的问题不是重点。是否可以容易理解，阐述是否全面反到成了问题。今年也要review这部分代码，争取让用户在看过我们的架构文档（当然是给用户看的那一部分）后就能对设计自己的程序心中有数。
　　设计文档。这部分就是头痛的地方了。一份说明目前代码文件的组织的文件是必须的，但现在这份文档已经过时了，需要更新。每个模块的设计文档都要及时更新，我看是很难做到了。我的想法的，把我们的设计写到每个模块的主要的源程序里。在每个模块的主源程序文件里，应该有这个模块实现的基本想法和流程（包括数据流和程序流程），对主要的数据结构，变量和函数应该有比较详细的介绍。每个源程序里都应该有对这个源程序的说明，包括主要数据结构，变量和函数。还有就是程序的代码和注释的review。