软件bug的沉重教训

几年前在某个网络设备项目中，我负责的PCI总线数据传送程序出现一个bug，但该bug极少出现，故在调试期间筋疲力竭的情况下被忽略了。其后我离开了这个项目组，大半年之后，我再次去该项目组时才定位到该问题的真正原因。

但此刻这个bug已经导致了巨大的损害，即耗费了我的一位好同事的巨大精力。他本来负责上层软件，并不熟悉该底层驱动模块，却不得不付出巨大努力来解决这个底层bug，可想而知是多大痛苦，多大负担和损耗。 

大体上，传送程序是操作一个环形队列，使用3个指针来指明"准备好/未准备好/空"，指针分别由总线双方来操作。这个3个指针的环形队列操作方式是我自己创意出来的，跟平常的I2O模式不同。印象中严重的bug出现在指针操作的时序上，也即怎样保持操作的原子性，当一方操作时不被另外一方打断。 

问题的详情已经记忆不清楚了，但是一些教训至今依然记得很清晰：
1、对于电信骨干设备这样极端紧要而决不允许有任何问题的产品而言，设计要尽可能简单，且尽量重复别人的设计，比如仿照标准的I2O。自己设计一套的话，稍微复杂一点就容易出现逻辑陷阱，陷阱可能极其微妙而极不容易被发觉；
2、如果通信的双方分别由2个人完成的话，一定要确保双方的交流，足够的面对面讨论和调试时间，因为任何"详细"的通信协议文档都可能有细微的陷阱漏洞，足够时间的面对面交流会很有助于发现这些漏洞。
3、可以肯定的是这样复杂的程序一定有bug，故一定要设计全面周密的测试方案，不厌其烦地做大流量和长时间的测试。当时可能会多花10天或者20天，但后面就省下我同事大半年的痛苦！