工程移植还看模块划分

         越是接触客户越是对“客户的需求是五花八门的”这句话感触良深。两年来没少花心血作出了一系列我们所谓的“标准品”，多少也还是获得了一些在我们这个行业里称之为“系统集成商”们的认可和嘉许，尤其是目前手头唯一有些差异化卖点的串口控制视频带图像和字符叠加的模块。从两年前开始第一台样机的原型开发到现在逐步的优化成型，细数目前拿了样机或是有个非常小批量订单的客户们，有意思的是他们基本都是个XXX所或者总之是不差钱的主儿就对了，马后炮说我们的预算是你们报价的多少倍的客户也有。这些不差钱的主儿当然也有其五花八门式的差异需求，感觉上我们的“标准品”已经沦为了不折不扣的“标准展示品”，无奈这就是这个细分行业的特性和现状。话说回来，此类非主流的应用，做到这份上，真的不是玩笑话，都有些感慨“有人掏钱让你做项目就可以躲在被窝里偷笑了”。

         还好，这些差异化只是在原有样品的基础上做加减法，当然是加法多一点，在涉及到鱼和熊掌的情况下也会勉为其难的做一点点减法。为了俘获客户的心，身为工程师的我们虽有些无奈但也认了。在和客户需求或功能确认过程中最怕“秀才遇上兵”，不过话说回来，更多时候也能切身感受到对方工程师的合理性需求以及建议中透出的几分睿智，于我们这般年轻的工程师来说，也是一个难能可贵的学习机会。所以，优化、改进，形形色色的特殊要求，都不要紧，其实都是一种产品的完善和促进过程，需求本身是死的，就看你如何对待和处理。

         最近做了一个理论上是“体力活”的“脑力活”，某个“标准品”中能够实现2路视频2mux1单路可切换实时显示的效果。而客户的要求也简单明了：在此基础上，再增加两路视频缩放后同时显示的功能，即两路实时显示。理论上也不难，从内部逻辑功能性角度看也就是如图1所示的功能块复制而已，不过在此功能块复制或者说复用过程中，也存在很多过去不曾留意的大学问。

图1 功能复制

         图1的功能扩展上，新的原型设计点只有SDRAM写数据前的仲裁逻辑部分，而这个部分要做好来，非得在原有工程基础上下一些功夫才行。当然了，除了这里的硬功夫——仲裁逻辑之外，由于大部分工作是对原有模块的复用，因此模块的重新划分也非常有讲究，甚至可以说，这是特权同学在这个改进项目上感触最深的“基本功”。

         举个简单的类似模型做一些说明，希望有助大家理解这个稍微也有点“只可意会不可言传”的知识点。如图2所示，一个含模块A\B\C\D的工程，其中C模块下有C1\C2\C3功能块。针对一个特定的应用，需要对该工程进行升级，其中涉及模块A\B的复用，模块C下的功能C1\C2的复用，同时需要简单修改功能C3和模块D进行新功能的整合。

图2 原有工程模块划分实例

         通常来说，一般的工程师接到此项任务可能三下五除二，对整个工程源码进行改造后的模块划分大体如图3所示。当然，针对我们的新需求来说这种改法直观明了，可谓“指哪打哪”，可惜现实感觉并不那么“酣畅淋漓”，甚至很可能整合得有些“情不断理还乱”，尤其当大多数应用中工程师遇到的情况要比这复杂得多。

图3 传统工程模块划分方法

         而在面对如此任务之时，特权同学还是总结出一个小妙招。在分析了既有工程模块的划分以及新的功能需求后，可以先“磨磨刀”，如图4所示，对原有工程模块重新做一次划分。根据需求一般可以将模块分为三类，一是复用模块，二是需要修改模块，三是无需更改模块，此例中主要是前两类模块。模块A和模块B属于复用模块，图4中将其重新统归到模块1中。原模块C比较特殊，其内的三个功能块既有需要复用的也有只需要修改的。因此可以将这些功能块在新的模块2下再细分为两个模块，模块2.1包括需要复用的功能C1和C2，模块2.2则包括需要修改的功能C3。如此一来，对于模块的复用和修改就非常明确和便利了。

图4 原有工程模块重新划分

         最后，可以整合出如图5所示的最新功能模块划分示意图。新的模块划分可谓清晰明了，既能够重新理顺了功能块，又可以让工程师大大加速移植效率，并且降低犯错的几率。

图5 新的功能模块划分

         虽然功能块可以这么按照需要对复用、修改与否重新划分，但是工程实践中问题往往要比这复杂许多，这里只能起个抛砖引玉的作用，主要还是靠大家开动脑筋做好前期工作，相信总是会有一套可行的模块划分或者说技巧方法可以大大提高工作效率的。