项目总结（按照接口编程）

 

原来一直做c的项目开发，系统还算稳定，做了差不多3年，核心的代码都重写了2遍以上。去年开始做新项目，为了提高开发效率，决定上c++。

 

c++就是好呀，成熟的库一大堆，于是选定了boost、ace作为系统的主要支撑库。boost还不错，块分的很好，团队学习起来很容易。ace就有点麻烦了，封装层还算易学，框架层就比较复杂了。还有就是ace一些比较特殊的代码风格，也着实花了一些时间。

 

       于是风声水起，项目就在去年8月的某一天开始了。按照原来项目开发的经验，把项目分成了若干子项目，都做成动态或静态的链接库，把变动或有替换性的做成动态库。结果问题来了，接口上c++还是必须退化到c接口，完全没有好的方案来实现，最后做了妥协，用了一段宏封装的对象的传递。（后来看到ace上好像有相应的解决方案，不过好像比较复杂，没有仔细研究。）

 

       到了12月，项目还算顺利，已经做到大半。结果需求变更了，很大的变更，公司希望我们的框架不光实现旁路模式，还能够实现网管模式，原来的层层缓冲的框架完全不行了。还好，模块化很好，我们决定快速扫尾（把各个模块重构解决耦合的问题）。然后甩掉目前的烂摊子，进入下一个迭代。结果发现所有动态链接的地方多不错，因为简单的c接口决定了其合理的移植性。而c++静态库的就麻烦多了，项目之间的依赖变得极为复杂。看来还是经验不足呀，在接口上依赖过多，最后费了很大劲才解决。

 

       这个时候项目的代码量已经超过60k了，特别是跟项目同步开发的分析模块，已经移植了大量原有代码。结果现在接口又做出重大调整。没办法了，只有做一段代码来桥接，效率极差，但功能是有了。

 

       第二次迭代开始了，于是乎原来的问题全部又可以解决了，重新审视设计，其实项目没有做到真正的按照接口编程，层次结构也不够清晰了，原来制定的分层，模块，都出现了很多的穿越者，为了某个功能的穿越，为了原有代码复用的穿越，甚至是硬件驱动问题导致的穿越。每个模块都被开了很多洞，来了很多外来者，为什么我们都没有发现呢？工期，进度也许是原因。但就这样无能为力了吗？

 

       接口是需要精心设计的，可原来c的为什么没有遇到这么多的问题呢？原来有一套虽然老化但是稳定的接口，任何人都不敢对接口做出太多的改动，因为谁都害怕接口改动会带来不可预知的问题。为什么现在c++了反而大家都敢随意的改动接口呢？

       新的项目，本来就不稳定，都不怕增加新的不稳定性；  没有强有力的去约束接口的重要性；因为强调敏捷，所以代码没有了所有权，大家敢于去触碰所有的细节。

 

       结束也是新的开始，约束接口，重构架构。