cbwfq移植的思考

    当我用一天的时间移植完代码，发现功能竟然实现了的时候。我有点被自己吓到了。如此顺利的结果真的是不在我的计划之内。甚至我已经做好了流量不通，长时间调试的准备。但是静下心来想一想，这不是偶然。 ­

    因为在这之前，我几乎花了两周的时间来熟悉相关的代码。可以说我用了两周看代码的时间，换取了这一天写代码并调试成功。这样做是否值得呢？我现在没有办法获得如果我不这么做的话，花费的时间是多少？但我内心的成就感告诉我，这是值得的。我想把这一次的经验做一个总结，以启发更多的思考。 ­

    1.在头脑中思考得越细致，越能够节省调试的时间。 ­

    这句话看起来很平常，但是以前我写代码却不是这样的。记得在刚开始接手一个任务的时候。我在没有将前后相关的流程看明白的情况下，就开始写代码。使得调试很不顺畅，光是定位问题就花了很长一段时间。 ­

    可能在开始时，由于时间上的原因，我们不可能在熟悉了所有的东西之后，才开始写代码。但是我要说的是，花在熟悉代码上的时间是值得的，它无形中节省了很多调试的时间。 ­

    首先，要弄清楚你做的东西的基本原理。在代码级别它是如何实现的。它的整体架构，数据结构，流程。 ­

    其次，设想数据包过来，代码是如何一步一步走的？微引擎中的内存是如何分配的？在运行的时候，内存中的值如何变化？线程之间如何切换？信号如何同步？ ­

    然后，考虑特殊的情况。比如第一个包进来的情形是怎么样的？当队列的长度超过了原先的设计时，会出现什么样的情况？这时应该如何处理？当然有些特殊的情况，是需要在平时的工作中积累的。往往查过了相关的故障才会有深刻的印象。 ­

    将这些问题弄清楚之后，写代码就比较有把握了。 ­

    2.将需要解决的问题罗列到一张纸上，按照重要性，一个一个的解决。 ­

    采取这个策略也是被逼出来的。原来，我自己其实是个没有什么计划的人，随性而为。但是我发现当一件事情稍为有点复杂的时候，需要采用这个办法来理清思路。这样做起事情来心里会更安稳一些，不会出现胡乱做了一通之后，总是担心自己有什么遗漏。 ­

   写的时候，其实也是一个思考的过程，可以发现自己思考的盲点。更重要的是，你可以拿着这张纸和同伴讨论，完善的想法和好的创意往往就在讨论中形成了！­