近期总结（上）

系统软件是最复杂的4类软件：操作系统、编译器、数据库管理软件和协议软件。

在学基础理论的同时，需要将理论与实践相结合，就一定要提高自己的设计实现水平。在看一些静态分析的材料时，知道他们讲的头头是道，可是究竟怎么验证、如何实现？首先需要理解第三方的编译器或者分析系统的框架，然后在其基础上做一些修改。充分理解别人的设计、实现和技巧是很困难的。开始时看一些“轻量级”的编译器就会比较艰难，后来去找了一些分析框架仔细看了个把月，发现既难（他们通常用函数式语言，开发和调试环境不太熟悉）又不完全符合功能需求，这个框架太难，以至于当我不得不返回到那个“轻量级”的编译器，发现其实它确实很简单（晕倒），于是在编译器基础上解决问题。

为什么会感觉困难呢？

因为我少有驾驭复杂系统软件的经验。

有没有办法解决呢？

我想解有两方面。

1）实际的工作。

  It depends。这么说是因为不同的项目、任务产生不同的经验。有一些商务智能系统也很复杂，复杂之处在于一方面众多领域知识的交叉混杂，另一方面则是“需求”频繁变化导致系统的设计、实现的扰动，以至于有人提出“要将用户看做系统的一部分”，以此缓解设计师对用户需求变化的反感，希望他们“拥抱变化”。而我的工作经验告诉要我遵循严格（至少是流程上的）的设计开发，高度重视编写文档和保证代码-文档一致性，最重要的是对可靠性的严格要求。对提高可靠性的方法总结下。

分四个方面。

一、设计。

1使用符合性能要求的algo，证明algo的正确性，分析algo和系统的时间空间复杂度；

2划分软件层次、模块和外部接口，设计桩程序；

3考虑并处理algo和sys的边界条件；

4考虑保存系统的运行日志。

二、实现。

1防御式编程；

2遵循国军标和其他用户指定的编程规范；

3使用测试工具，单元测试+回归测试，100%覆盖；

4、验证时空复杂度是否与理论分析匹配并分析。

三、测试。通常是接口+联试。

四、验证。拷机测试。

如果设计师和程序员理论够强，对可靠性要求为A，考虑用

1计算机辅助证明定理，引入形式化设计方法开发，可以用法国人的那套Atelier B。

2尝试用模型检测工具验证正确性，比如spin之类。

2）读书。先不提理论基础的事情。多读算法、算法分析的书，是提高技术基础的办法。读书读多了会有一种恐慌感，痛觉理论无处发泄，屠龙之技尔耳。读源代码是提高技术实践能力的方法，也是保持和提升自己战斗力的办法。

  几年来，我只读过3个程序的源代码，感觉都有收获。第一个是iometer，intel设计师开发的磁盘/网络测试工具；第二是ipmessage（飞鸽传书），日本设计师写的即时通讯工具，设计简单而功能强大；第三是lcc编译器。这三个都是工业级的产品，不是面向教学的简陋工具。最简单的是ipmsg，很容易修改供自己使用。我之所以看ipmsg的代码是因为曾经有个同事开发了一个高速数据传输工具，故障频发。我在离职前有过用ipmsg模块替换他的模块的想法。看iometer的代码初衷是为了解决数据的高速记盘，后来写了《用IO完成端口提高读写速度的探讨试验》的总结。收获是真正理解和建立了功能和界面分割和模块化的思想；树立了理论指导实践的意识。在此之前我写的程序是将功能和界面处理杂糅在一坨，过分重视UI，解决问题时不从理论的角度分析。ipmsg&iometer的阅读算是任务驱动的，后来lcc的阅读是兴趣驱动的。上研后希望做点“智力密集型”的程序，觉得编译器比较好玩，而且需求变化小，受外界环境干扰小。就选了编译器代码作为阅读对象。lcc的代码比较混乱，为了效率他hardcode了lexer和parser。随后又看Holub的compiler design in c，这书很好，90年的，难度不大代码又很清楚。不知为何国内不引进。龙虎鲸我都有，甚至虎书的ML版我也跑国图复印了去读。读这些的收获非常大，我深入理解了语言，也看到了如何用几行小小的代码实现心中的概念。在设计中，想达到我手写我心很难，即使是从算法到程序都不是想象的那么容易。