实战uC-TCPIP(后续)--嵌入式开发的一些个人经验

最近忙的项目，估计是我在目前公司的最后一个项目了。我的任务是负责一块接口转换板的程序。实话说这个程序没什么技术含量，纯粹是应用协议的转换和物理接口的转发，完全可以用一个上位机软件代替，由于某些历史原因出现了这个怪异的解决方案。总结一下这个项目的开发过程，主要是在业务抽象、模块化设计、测试驱动和版本管理等方面多积累了点经验。
我所谓的业务抽象其实就是把类似的业务用相同的接口统一起来，通过中间层作为业务需求和业务实现的桥梁。增加中间层的代价是增加运行开销，好处是需求变动时修改容易。针对目前这个接口转换板的设计定位，这样的代价是值得的。而且我不希望单纯为了这个需求写这个程序，最大限度的重用是我设计的原则，这里涉及到模块化设计。
我理解的模块化就是堆积木，一个模块实现一个明确的功能；模块还可以细分，最小粒度的模块实现一个单一的功能；一般用一个.c和.h文件代表一个模块。归因于我设计水平低下，常常在实现的过程中需要增加功能调整接口。有感于以前看的万行文件和千行函数，我现在是新建文件控和新建函数控，工程目录下有很多.c.h对，每个.c基本不超过2千行，每个函数不超过200行，超过一百行的函数很少，主要是uCOS任务函数的消息处理循环。以前那个让我骂街无数次的程序，很大一个问题是如果想从里面拿某个功能出来修改或者移用，会发现像掰莲藕那样，处理那千丝万缕的联系足够头疼了，还不如自己重新写功能。模块化的设计，不只是方便未来维护修改或者重用，其实也提高了当前开发效率，例如实现单元测试，需要比较独立的功能模块。只可惜在急功近利的山寨厂里，不管是什么编程语言，总能看到慢慢变得臃肿的代码。新手们不敢轻易修改，熟手们忙得没时间完善，老手们懒得再去理会。开发就好像是使用一次性餐具，想捡回来，发现洗干净的代价远比买新的高。不知道这种状况在行业里占了多少比例？希望只是极少数。
说到单元测试，我是去年才开始实践，而且一般只关注那些涉及到不那么直观的数据结构和算法的模块。今年仿效测试驱动开发，有好几个模块尝试先把测试框架和测试用例写好，然后再逐步完成模块的实现。看着一个个用例逐渐从全部failed到全部pass，颇有成就感。感觉这样开发的好处首先是对模块接口设计的完善，在编写测试框架和测试用例的时候可能会认识到模块接口设计存在的不足；其次是更注意对异常情况的处理。目前如果每个模块都这样做似乎花销有点大，毕竟增加了额外的开发时间，不过有可能减少调试时间，相信以后这是趋势。
至于版本管理，一直是软件开发必不可少的。最近几乎是一个人在开发，而且是一个功能接着一个功能，几乎没有开分支。得益于svn对rename、copy or move等的支持，我可以放心调整模块的命名和程序的结构，不断改进设计时的缺陷。不过由于懒，每次改动了好几个不相干的地方才提交。其实反正用的是私服，没有什么规章制度，勤点上传没副作用。我认为这种规模的程序，一般编译通过，在板子上能跑起来，就可以上传了，尽量保持每次提交只有一个相对独立的更改。比较疑惑的倒是像单元测试这样的辅助功能代码，到底该放在什么地方，应不应该作为这个工程的一个部分？还是专门为所有工程建一个单元测试管理？粗略浏览了google svn和sourceforge的一些项目，目前还没有收获，个人倾向后者。
最后，再总结下另外一些有意思的地方。这个项目的硬件是重新设计的，直到现在还没完全调好。由于缺乏模拟环境，我的前期工作一是在另一个平台完成uC-TCP/IP的移植，花了不少时间，二是在windows下把核心业务实现了，花了几天弄了一个基于Qt的模拟软件。现在，因为我们设备研发的滞后，在参与大系统的联调时我们主要是用那个模拟软件去充场面，忽悠忽悠...前期的准备工作很有用，在新平台移植uC-TCP/IP和实现简单的socket花了不到两个星期，核心业务的移植花了不到三天。倒是协助硬件调试花了几乎三个星期。我对那个模拟软件感觉很“得意”，因为在和大系统的其他设备、软件联调的时候，它扮演了一个比较可靠的角色，协助团队快速定位并解决了不少问题。更重要的是，它为我们自己的设备赢得了宝贵的额外开发时间。假如我们过早地把半成品拿去做联调，下场可想而知。还有一个“有趣”的细节，当我弄好模拟软件去找别的设备测试协议时，居然发现业务应用协议是基于TCP不是UDP(我们的需求管理...我当时想撞墙了)。在Qt强大的类库和使用手册帮助下，过了不到一个小时，一个从来没做过TCP程序的人做出了他的第一个TCP服务器程序。我不禁感叹，不愧为RAD，Qt开发也真够傻瓜式的；同时我也明白了一个道理，我这样的水平真是不能靠Qt吃饭...