乱侃特性开发

    从事网络软件开发已经四年，发现总体上上层业务的特性开发结果和底层驱动的评价相差很大一截。

特性开发不好做，只要任何一个环节出现问题，结果就已经注定。甚至任何环节都不出问题，结果还是可能会悲剧。一个同事写了一万行代码，验收时没有发现这一万行代码的问题，验收结果却是差。只是因为忽视了相关组的两个小问题。

上层业务的特性开发更困难些，因为涉及到组网，网络结构是无穷无尽的，只能选取经典组网进行系统测试；涉及到规格，分为小于规格，满规格，超规格三种情形，我们只能将大部分精力投入到小于规格时的测试；涉及到业务组合，业务组合无穷无尽，只能选取联系比较紧密的业务进行测试。当组合，组网，规格结合在一起时，永远无法穷究所有的测试点。开发人员的测试过程  注定存在漏洞，所以鉴定中心从来不愁发现不了问题，每次都放出话来：测不出致命不许停下！

受限于时间和人力成本，测试时，开发人员总是采用白盒测试，专业测试人员也是采用灰盒测试。黑盒测试在这种情形下失去了效力。开发人员总是在经典组网下，小规格，部分业务组合下测试，而测试人员总是在不规则，大规格，大量业务组合下测试。测试的结果很有可能不同，发现一些开发人员没有注意到的盲点。任何版本稳定下来都需要一个过程，总要经历单元测试，集成测试，系统测试三个环节。

彼得定律在IT行业同样适用: 每一个职位最终都将被一个不能胜任其工作的职工所占据。层级组织的工作任务多半是由不胜任阶层的员工完成的。因为人员的流动性很大，老员工是宝贝，往往从事系统分析的工作，特性开发负责人往往是新员工来完成，新员工总是在边学习适应边特性开发。在没有了解相关业务所有功能前就完成了特性开发，往往知其然不知其所以然。犯错误是新员工的权力，在成长的过程中跌倒在所难免。

根据几年的观察所得:业务功能实现很困难，往往需要持续三轮以上系统才能慢慢稳定。

今年分析并负责了两个特性，BFD FOR INTERFACE和BFD 支持堆叠特性。这两个特性都出现了难以接受的问题，都出现了漏分析和漏测的现象，bfd for interface是回切丢包，而bfd 支持堆叠则是远端的ipv6 bfd会话建不起来，bfd for te lsp基本功能不可用。因为outlif硬件表项中没有保留标签，跨框后无法转发出去，

bfd for interface这个特性设计的时候就存在重大缺陷，而这个缺陷一直隐藏到验收，因为低估了复杂度，因为系统测试时做得非常随意，所以一直到验收才发现。没有任何借口。

远端ipv6 bfd会话建不起来的问题，这个也是sow中分析遗漏，应用中很少出现，在分析时忽略了，link local表项的特殊处理，取下一跳会引发这个问题，但是sow并没有发现。这个问题无法避免，问题在后面，这种设计方案已经被回退了，但是代码却没有回退，完全是代码管理不善引起的。版本直接同步代码出现了问题，导致代码被遗留下来。

      SOW的误分析和漏分析是能力问题，一方面，需要通过广泛涉猎和深入掌握业务来提升自己，保持空杯而且好学的心态。另一方面，在方法上尽量减少这种可能，应该列出功能大纲和可能组网，逐一分析。

    特性开发是如同盖房子，环环相扣。而且有多米诺骨牌效应，缺了一块就再也无法推倒所有的骨牌。特性开发很像种菜，先是圈定一块地，规划各个地方种什么，然后施肥种菜浇水。采用科学方法，才能结出甜美的果实。

本文出自 “在茫茫网络中跋山涉水” 博客，谢绝转载！