多人协作的项目中应该注意的问题

（*************这是一个相当个人化的笔记，不适合通用阅读，请见谅。*************************）

现阶段我正从事LTE eNodeB 的空口协议软件开发，这一周测试了一个自己维护的模块 PDCP的 重建立功能的测试。 持续了一周，最后的问题都出在自己模块之外的配置管理相关的代码。

从上周三早上开始调重建立，到这周三晚整整一周时间，此次调试的经验教训总结并没有结束，还有很多值得反思。

从开始到结束总共就三个主要问题：第一个问题是消息分发不支持L3配置的 suspend 消息类型，导致L2的PDCP和RLC不能及时suspend； 第二个问题是 SRB2和DRB 在重建立后没有及时从suspend状态恢复到running 状态，导致承载于SRB2 上的上行直传消息收不到； 第三个问题是PDCP DRB 维护的上行的动态参数 lastSubRxSn(上次向高层提交PDU的序列)应该在RRC 的connected状态下一直被维护不被外部更改，但在重建立重配置时将其重置为默认值4095，导致重建立后上行DRB数据不能上发到S1。

出现第一个问题的原因和一般性心理因素有关：大家一般都对自己负责的代码小心谨慎地维护好，对他人维护的代码往往不关注，比如<消息分发>,我自以为L2L3接口定义的已有消息类型都会支持……，没有亲自走读消息分发的代码去核实。

第二个问题是编码问题，在for 语句里没有正确使用break语句。

这三个问题有个共同特点：都在PDCP模块之外被维护，测试时没有引起重视，没有做集成测试。

自己在做重建立单元测试时仅仅专注于自身PDCP模块内部的协议处理，没有测试外部的配置消息。其实只要一个集成测试模拟从L3下发配置消息到<消息分发>再经过<OAM>配置L2的PDCP和RLC，然后再到PDCP内部协议处理，这一个集成测试就能将上述三个主要问题都暴露出来。

为什么没有做集成测试呢，这也应该反思。

之前领导也强调过集成测试的重要性。当时准备写集成测试时发现不仅要配置不太熟悉的L3消息，还要熟悉消息分发的处理过程，还要熟悉OAM的处理过程，感觉挺麻烦，而留给PDCP重建立单元测试只剩一天时间，就决定暂时放弃集成测试，直接测试PDCP。虽然现在看来做集成测试这些都没有想象中那样复杂。终究原因：不仅要熟悉自己模块的代码，还得熟悉和自身模块相关的代码，比如消息分发和OAM，重建立过程就要涉及到这两个模块。这样在考虑集成测试时就不会有任何犹豫和迟疑了。

以后不能因为时间紧就“偷工减料”，要做充分的单元测试（集成测试）。