TCE1保序功能的开发

         “TCE1保序”功能的开发过程从10月底到11月底，算算应该有一个多月的时间了。目前总的代码行数为1700左右，基本功能自测完毕，已经提交测试了。从开发的角度来说，这个任务应该是告一段落了。我也想停下来写写，这段时间的收获。

         这是我第一次真正意义上用微码进行模块的开发。从需求的明确，到方案的敲定，再到代码的完成。整个过程都亲身参与。在各个阶段都有值得学习的经验。

         首先是需求：

         这个功能的开发其实是为了解决一个外场的问题。即报文由于传输链路的原因，从发送端发出的报文按序发出，但是到了接收端报文的顺序却乱了。例如在发送时报文的顺序是1 2 3 4 5，但是到了接收端收到时却变有可能变成了 4 2 3 1 5。我们要做的就是把错误的顺序的报文再重新排一次序，让他们在经过了处理之后，按照正确的顺序发送出去。

         从我接手这个任务时，得到的信息就是如上所述的。而后面的开发也确实是按照这个思路来进行的。

         但是我想说的是，问题的提炼是不容易的。真实外场的应用环境相对复杂，最初的表现是ftp传输效率非常低下，经常出现报文重传的现象。如何判定是这个问题导致的？前方的人员和老大们进行一定经过了不少实验和分析，最终提供给我们这样的一个开发任务。这个工作量我想不会比我的少。

         需求的确立是开发的第一步，如果一旦需求错了，那后面的开发的方向甚至结果都会事与愿违。对于我们这个相对大型的公司来说，结果对于作用力的反馈是很慢的，因此这里面就存在很大的风险。开发时的我，对于需求知之甚少，心里其实是挺担心的。

         现在我想，当时的自己应该更加主动，去了解清楚到底用户的应用是一个什么样的环境，我们做的东西能解决他们什么问题。这件事情是一定要做好的。否则后面的一切都是白费！

         其次，是方案的确立：

          这一部分是自己亲身参与的，老大们深厚的功力给我很多启示。部长从问题当中提炼出对于性能的要求，提炼出选择算法的约束条件。例如：从流量的大小估算出报文的时间间隔，进而计算出定时器的时间精度。从ping包的应用，提出对于刷队列条件的改进，从真实流量的序列号规律，提炼出第一个报文的特殊处理，排序算法的能力范围（排序队列的深度为16），以及排序算法的设计思路（采用最简单的循环数组排序）。

         对于一个做技术的来说，你可能知道很多种实现的方法，但是如何选择？现在我知道了，答案从实际的问题中来。如果最简单的方法就可以解决问题，就没有必要复杂。在实现的过程中，我也感觉到，简单的东西便于人的理解，出错的概率要小得多。

         这个过程是体现一个技术人员实力的地方，而自己其实是差了很多的。当时的自己把注意力几乎全部放到了实现上，对于如此重要的方面却忽视了。

         再次，是流程的设计。

         这个阶段要求的是思维的缜密。

         这个过程我的体会是，团队合作非常重要，要把你的想法和大家充分的讨论，进行代码评审。

         我自己不是一个牛人，设计出来的东西出现了不下20多个漏洞。有一次大家对我的设计进行评审，一下子提出了7，8个错误。当时自己很沮丧，师傅安慰我说，没关系，谁都有想不到的地方。谢谢师傅的鼓励！

         斌斌和大庆指出了我算法的致命缺陷。这也是后来使用循环数组的原因。当碰到“当前的序列号等于需要的序列号”（current sequenc = needed sequence）循环队列要出队的时候，对于队头指针的处理缺陷，是师傅想办法解决的。

         娜娜，小希，榨菜，虽然自己也有很多事，但是还是坚持听完了我的一次含金量不高的评审。小伍哥顶住了很多来自测试部的压力。也许你们觉得这些没有什么直接的帮助。但是，我要说，这些支持对我很重要，真的很感谢大家！

                 还有很值得一提的是，在代码评审中，在讲到多线程同步的问题时，部长给我们介绍了一种folding 技术，让我们大开眼界，后来的开发也是采用的这个多线程同步的方案。调试时，基本没有遇到过什么线程同步的问题。这种方案真是一件珍宝啊。

         最后是代码的编写了。

         由于有了上面的铺垫，到了这一步，其实要做的工作已经很容易了。代码的编写和调试，虽然也碰到了很多问题，但是基本没有什么大的阻碍，用的时间不长。大概一个星期就完成了。我想再次说明，没有前面的充分准备，如果在调试时来解决问题的话，代价是非常昂贵的！