abs项目 - 战线拉的太长

“从项目中来，到项目中去”。

坑是踩不完的，尽量做到不要踩重复的坑就好。

最近的这个项目，从2016的8月份左右开始立项，一直做到2017的2月份，还是有很多的问题在继续排查。其中暴露出来不少的问题。

现在回头来看，总体来讲整个框架其实并不复杂，只是牵扯的模块太多：

其中模块B，C，D是集成在一个进程中的，A单独跑一个进程。其中的数据流顺序如图所示，逻辑上是一个顺序线性依赖的关系，但实际上，软件的需求是最终的“7”对用户来讲要实时流畅，这就要求最终的运行其实是一个并行流水作业。

从2016开始的点追溯，有下面几个方面没有处理好：

用户需求没有转化为开发需求

项目开始之处，没有将用户需求进行量化，将其转换为真实可见的开发需求和性能需求，也就是，对其中的设计指标是不清楚的，这就导致后面一系列的开发决策是非常盲目且相当然的；

流水线

对并行的流水线设计原理不了解，导致时间片的设计和计算出错。这个问题属于知识盲点，后面单独针对总结。

数据到底走多快?

开始总是觉得这次是对硬件性能估计不足，但仔细分析这其实是个表面问题。

处于核心模块C开发时，对于依赖的A，B，D模块，都没有考虑依赖模块的处理性能（这个地方的性能可能是硬件原因造成的，也可能是软件原因造成的）。设计中只是考虑了“数据流向和时序”，但是没有考虑“各个步骤上数据到底能走多快”，导致了结合点的缓冲读写机制设计有问题；

集成经验不足

项目中牵扯对一个三方的算法库进行集成，“同名符号冲突”和一些库的缺陷直到后面要提交系统测试才发现。冲突的问题已经通过开发自检脚本来解决了，倒是“对三方集成库的单元测试”是个大问题。（后来通过readelf等命令解析编译后的段符号，比对重名，可以在集成前做重名函数检出）

要想办法将一个大功能完全可以先对其进行拆分，拆分到一定粒度的子模块后，在接合处编写DEMO对其验证，可以先把跟集成的库相关的代码实现，入口处进行DEMO测试后再集成到系统，不用等到整个系统完成了，把所有东西跑起来再去验证库。

可调试性是躲不过的

什么叫可调式性，就是这部分的数据流向对开发人员来说可以透明。

形式可以多样，或者是打印，或者是输出到文本。重要的是，存在不透明的数据，就会存在难以调试的缺陷，不要抱有侥幸的心理，调试的设计和开发逃不掉的。

沟通

拿不准的方案，要催着别人一起看。 

涉及很多人就及时开会，面对面效率高。

联调时，用原理和数据沟通。