怎样从阅读代码角度理解项目，一点愚见：
理解上重点要关注程序在做什么，而不是理解程序的控制流，如果去理解程序的控制流话，大半是体系架构文档不太上的了台面的缘故。
最近经历的一个项目很可以说明这一点。该项目的SAD（software architecture design）走了设计评审的流程，但是从SAD映射到模块设计阶段经历了类似敏捷开发的过程，从过程管理上来说是有欠缺的。和前期开发团队一起累代码的就是在参与极限编程，本人承担起了客户的角色，讲述了一个不很顺畅的故事，前期开发团队对已有的类似系统进行了二次开发以符合本项目需求，该过程也是对一个原型化系统进行迭代开发，这就跳过了外部设计文档应有的数据字典编制，尤其是项目成员更替的情况下对进一步的开发维护会设置一定的障碍。本项目开发的系统性质属于Shari
Lawrence Pfleeger所说的需求随外部环境变化而持续变化的E系统，这就需要对需求进行测量，即一个项目需求变更表，以定位变更的需求对体系架构的影响范围，进一步定位对代码的改动范围影响大小，以便当系统需求发生变化时，可以对这些变化造成的影响进行评估。
一般而言，一个正式的软件项目按照能力成熟度方法论进行过程控制，开发出来的软件质量是能够得到保证的。原因在于两个过程的保证：1，CMM要求对体系结构进行确认，确认是否符合客户的需求，反映在SAD文档中；2，验证文档，以保证开发人员正确的开发了系统。
由于是一个后台数据传输系统，所以日志模块的设计在SAD到coding的链路不畅情况下显的尤为重要。系统目前还只能说是近似可靠reliable，但还不健壮robust. 缘何不健壮？一个健壮的系统在不正确的输入和意外的环境条件下也是能够正常工作的。构造一个健壮的软件单元/系统涉及到质量控制，这就必须考虑体系架构中没有考虑的全局性问题，比如：数据管理，异常处理。异常处理需要在系统的范围内定下一个统一的基调，否则仍旧不是一个健壮的质量上乘的系统。异常处理就是对故障的识别进而处理的过程，故对正在查找的故障识别类型是关键。
正式的软件工程中认为故障有以下几类：
- 算法故障
- 计算故障/精度故障
- 文档故障
- 压力故障/过载故障/能力故障/边界故障
- 协调故障/计时故障 coordinate fault
- 恢复故障 recovery fault
- 标准和过程故障
文档故障通常会引发其余故障。计算故障也是常见的故障类型，如除0引发的浮点错就是计算故障。开发多进程并行任务容易引发协调故，典型的就是锁，资源，竞争场景。