1.3 亲历高复用研发模式

机缘巧合下，一次偶然，让我有机会参与日本东芝公司电制事业部G2平台研发，该平台是用于支撑东芝各类工业嵌入式设备快速研发的技术平台。这段经历，让我惊奇的发现其研发模式完全迥异于我以前的认知。这段经历不仅让我大开眼界，也开始倒逼自己认真思考这种工作模式的优缺点。为何要这样做样做的优点是什么是如何一步步迭代到目前这个样子的呢/p>

从表面看，这种研发模式最典型的特征是努力提升工作（包含代码，设计文档甚至培训讲义等，但本书以代码复用为切入点）复用率，当然还有很多可参考借鉴之处，本章我会和大家分享一些这种研发模式中让自己很震惊的特征。

在东芝内部，大家习惯将这种研发模式称之为“平台化”模式。不过平台化这个词估计早就被各行各业用烂了，担心大家望词乱生义，在本书中我喜欢称之为高复用研发模式，或者高复用严格平台化架构，但不可避免的依然会频繁使用到平台化这个词语，希望大家不要误解。

1.3.1 夸张的代码复用率

我刚加入该项目组时，是由一位做规约开发的工程师带我熟悉整个研发流程。借助这个机会，我有幸阅读了他实现的一个规约程序，虽然仅仅是电力系统最常见的IEC104远动规约，但让我在内心中重新定义了“代码复用”这个概念。

我们平时做产品，代码复用是经常的事情。我的产品中需要某个功能，而恰好你的产品中已经实现过了，找你领导商量一下，然后将代码拷过来改一改，OK，搞定。这可能就是我们认为的代码复用。

与我们不一样，该规约项目组复用时不是直接将代码拷贝给其他项目组，而仅仅将编译后的中间文件和头文件导入代码库，其他项目组用配置软件直接导出复用就好。

大家看出关键差异了吗，其关键就在于我们需要改一改，而这儿不需要。因为不需要将一份代码维护成多个版本，这才是一种真正的复用。注意，从今而后，本书中一旦提到复用，都是指这种一个字符都不用修改的复用策略。

做过产品的工程师都知道，即使同样是104规约，很多产品线都存在着多多少少的差异，各个市场也会提出一些特殊的需求。这种情况下，是如何做到代码完全复用的呢。我阅读并分析代码后，发现关键需要做到如下几方面的工作：

1. 需要抽象提炼各类数据模型api接口。
   规约程序需要访问很多具体的数据模型，如遥测、遥信等，这些数据模型在各类产品中概念大致相似，但或多或少的会存在细节上的差异，且会随着需求而持续变化。为了规约程序不受影响，就需要细致的提炼数据模型api接口。

2. 构建动态执行架构，兼容前后台，实时OS或linux等多种运行环境。
   工控产品应用领域差异很大，因成本或需求要求不同，有些是前后台裸系统，有些则会使用复杂的强实时OS，或者使用linux系统。大家都知道前后台系统是简单的函数调用，而OS中是一个个的死循环任务函数，不想分别实现一套104规约，就需要构建抽象层，兼容各种运行环境。

3. 构建规约数据参数配置表，需要维护软件或配置软件的支撑。
   各类装置虽然都使用104规约机制传输，但传输的具体数据却存在很多差异。因此，想让规约代码可复用，代码具体实现中就不能涉及任何特定的数据，用IT术语来说，规约代码只能针对数据接口进行编程。为了应对这种情况，需要额外构建各装置的数据接口配置表。如果规约传输的数据允许用户现场设置，该部分功能一般会内嵌在维护软件中，如果仅允许在厂内修改或合作伙伴二次开发，经常会内嵌在配置软件中（配置软件和维护软件会在后续框架设计中详述）。

4. 可扩展程序架构，以支持各种二次开发环境。
   104规约虽然是国际标准，但在具体实施的过程中，大家总是会忍不住去扩展或修改它，因此会诞生各种区域版本（我实现过特殊的中东版本）、工程版本、特殊需求版本等。如何应对这种需求呢好的策略是分层，将104规约最基本的功能作为可复用模块进行构建，并提供二次修改的机制。最常见的二次扩展机制有参数文件、脚本和二次开发环境等（这些机制各有优缺点，在后续框架设计中都会提及）。

5. 依据需求持续优化迭代。
   任何设计初期都可能存在不足，有些地方会考虑不周，而有些扩展选项又从未用过等。在实际工作中，我们经常是保持程序架构稳定，但会持续的优化细节。打磨的时间久了，我们就会惊奇的发现针对某一行业的程序改动频率会越来越小，此时，可复用的104规约模块就构建完毕了。

至此，我们终于完成了可复用104规约模块的构建。不知大家有没有意识到，其中提及的api接口、动态执行框架、配置软件、维护软件、脚本系统、二次开发环境等都不是104规约范围内的概念，为了完成104规约的复用，需要诸多模块配合，甚至平台级的支撑，而这，也正是可复用模块不容易做到的底层原因。

困难是有的，但如果你能闭眼想一想，假如我们的产品中，甚至我们部门负责的几条产品线，更甚至我们整个公司，所有的软件模块都是以类似这样的模式构建的，会是怎样的一种情景呢。下图是我当初参与具体研发工作时导出的可复用模块接口配置表（留意滚动条，最终会通过配置软件读取生成接口文件并下载到设备中），大家能感受到我当初的那种震撼心理吗br>

基于这套研发模型，公司会要求非创新性的改进型产品，代码复用率要达到70%以上。实际上随着时间的积累，大多数产品都是特定领域的小改动，代码复用率经常高达90%左右。

一边是上班单纯的工作，下班大家经常聚在一起喝茶烤肉聊天从不谈工作；另一边是追求加班是一种奉献精神，大家整日忙的头昏脑涨，做着重复的工作，聚餐时还要经常在领导面前高谈阔论以表明自己是多么的全身心投入；最终可悲的是数以几十倍记的工作效率差距。

1.3.2 如何做出高端产品

在工控领域长期工作过的工程师，自然而然会接触到很多高端产品，其中很多都是名不见经传的厂家做出来的，但人家的产品就是用着可靠不给你惹事、长期性能稳定、精度高……，如我们用到的一种弹簧夹头，如一种要求数十年不漏气的密封圈，如在地铁非常潮湿环境下用的电气控制设备，如可长期稳定测量的高精度电能表……。

我以前接触的不敢说都是低层次产品，但绝对是每个大城市都有那么几家能做的产品。因此，大家只好拼价格，拉关系，堆售后。有时大家也会眼馋那些高端产品的利润率，拆开研究研究好似也没什么，也会集中人力物力进行尝试，但不知为啥，做出来的产品总感觉会差那么一点点。幸好，我加入的这个项目组，给了自己一次近距离观察思考的机会。

记得一次同带领我的规约工程师交流，我惊奇的发现他对规约的理解模式和我完全不一样。在我自己的传统观点中，规约不就是约定双方帧结构和排列顺序吗，如下表，是我设计的维护规约中的读遥测功能帧。

作为对比，以前我们修改一个数据模型结构时，总是需要小心翼翼的重新排列规约结构，然后在调整规约两端程序，而现在，仅需要修改该数据模型对应类程序这一处。而且，基于这样的思维模式，也更容易理解电力行业新涌现出来的各种规约，如IEC61850规约，其层次结构更复杂。

理解了他的思维模式，我突然有一种豁然开朗的感觉。大家的计算机能力差不多，但这个同事为何能在规约领域比我高出一个层次呢。从表面上看，因为我要负责整个产品的研发工作，会涉及到多个领域，而他仅需要思考规约即可，但如果深层次思考，好似并没有这么简单。

该同事虽然仅负责规约开发，但有两个额外要求，第一要负责全部门几十款产品的规约开发，第二需要构建高度可复用的规约模块，其工作量并不小。以该同事的话说，他一开始也是负责具体产品的，仅仅是后来发现规约模块几乎每个产品都有，然后在慢慢的复用过程中，他的精力才逐渐的全部转移到规约这一个点上了。因此，复用是专业化的前提，而专业化是复用的衍生品。

同规约类似，我在项目组里发现了有专门研究脚本的，专门负责维护软件的，专门搞算法的……。记得有个搞了一辈子算法的老头特可爱，头发都白了，退休后又被公司返聘，他特别喜欢给我们讲课，讲解地铁机车启动时的大电流和故障时的大电流有何区别。我不是专业人员，基本听不懂，顶多听个热闹，但也会被老人那种专业的职业素养所折服。

2. 集成测试

每一个模块都尽善尽美，并不等于组装出来的产品就是优秀产品，而集成测试就是将散落的模块打磨成一款产品。在我以往的经历中，我带的研发团队好不容易将产品做出来了，大家都试一试，应该是好用的，感觉就大功告成，可以交给测试团队了。但这次研发经历，有一条策略，颠覆了我的原有观点：集成测试是研发组份内之事，只有这样，才提交的是可测试的产品。

我以前很少做集成测试工作，为了增加体验，有一次一款样机研发完毕后，我耐着性子认真且完整的做了一次集成测试。那次测试前前后后差不多花了一个半月时间，我惊奇的发现自己已经交付的产品，每个工作日竟然还能发现的多达三处bug或改进点。以往我们研发组做的产品交付后工程人员或用户总会反馈一堆不舒服的地方，经过这次集成测试，类似反馈竟然大幅度减少了。至此，我内心才真正认可了集成测试是研发组份内之事。

很遗憾的是，现实世界中，研发人员好像都不太乐意做测试工作，工作即使安排下去，也会出现很多偷懒的情况，很多测试用例大家会想当然的认为不应该有问题而直接忽略。如何克服呢这次经历中我看到了一个有趣的小技巧。该跨国公司员工做测试时，首先将测试用例全部打印出来，测试人员每测试一项后，在记录处盖上个人的戳记（一种电子化设备，包含名字和时间，同时也是个人权限签名标签），最后在扫描电子化归档。现在全球都在推行无纸化办公，为何还会这样逆潮流的行为呢。交流后，我才意识到人们在签名时，会因仪式感而多了一点点慎重情绪，纯电子化的东西大家反而会因虚无感而轻视。一个小小的技巧，既尊重了人性，又增加了测试效能，我很佩服这样简单但有效的管理艺术。

为了做好集成测试，重点在测试用例。过多和繁琐的测试用例会降低执行的可行性，最后极容易让集成测试过程形同虚设，如何保证覆盖必要的关键环节，且有效的降低测试工作量，是一门艺术，没有标准答案，是反复权衡和迭代中的产物。同时，集成测试用例又是一个闭环节点，现场反馈的各种问题，都会逼迫我们重新审视测试用例。

3. 功能测试

既然测试人员将所有的测试都做完了，要测试组干嘛呢是我一开始接触集成测试时，脑袋中自然而然冒出来的问题。后来反复观察后发现，这两类测试是不重复的，他们的侧重点不同。

集成测试更多的是站在研发人员角度进行测试的，会更加侧重接口，一些特定情况下的特定处理等。而功能测试时，测试人员更多的是站在用户角度对产品进行测试的。如要求拿到的产品必须是包装好的，会检查各种资料是否齐全，会模拟手拿箱子不小心跌落在地后会发生什么状况。会模拟各种真实安装过程，如人工接线时螺丝刀不合适，是否会造成永久伤害等。

在公司内部，大家称集成测试为对内测试，功能测试为对外测试，我仅是为了大家理解方便，将其换成了软件工程中的常用名词。但仅内外这两个名字，就能形象的指出他们之间的区别。

很多具体的测试工作可以深化，如重复的测试工作可以搞各种自动化测试等，以提升工作效率。集成测试不容易外包，但功能测试可以外包，这样可以缓解研发进度和人员紧张之间的压力。我就曾经带着一个团队承接了一个功能测试外包项目，因成绩突出而获得中外双方的表彰。

4. 全面质量管理体系

在平时工作交流时，架构师经常给我们讲一个丰田纺纱机的故事（在那之前我一直以为丰田一开始就是造汽车起价的），其中最重要的特性是丰田纺纱机内部包含一个检测模块，一旦检测到问题后会自动停机。这样的好处是，每台纺纱机不需要一个人时时刻刻盯着，而是一个人可以管理多台机器，如果发现机器停下来，调整一下，就可以从新运行了。

将检测模块内嵌到产品内部，即使出了问题，也有策略去应对，这就是破解长期质量问题的关键策略。

当然，想将检测模块内嵌到产品中并不是一件容易的事情，需要在一开始架构设计的时候就给予充分的考虑，如装置发生异常后，有足够的异常记录信息用于分析问题；如在系统联调时，有足够的边界信息缩小问题范围；如某些行为同预想不一致时，有策略可以分析程序流……。记得一次我们为了分析广州地铁运行异常现象，采用专用设备以高频率的模式抓了真正一周的运行数据，1T大小的快速硬盘被塞满了好几块。

质量问题总给人一种虚无缥缈的感觉，我以前除了对下属员工叫嚷要仔细编码多多测试外几乎毫无办法，现在，接触到这种春风润物细无声的质量提升策略，内心还是有蛮多感触的。后来，顺着这条路，我才开始慢慢的接触到全面质量管理体系（俗称TQM），深入了解戴明14条，才好似给自己打开了另一扇窗户。

1.3.5 有序的生产研发管理体系

在我的职场生涯中，除了刚入职那几年，感觉剩余大部分时间都是被身不由己的赶着往前走。刚开始是被各种事推着走，经常是周一刚刚制定好计划，一个现场电话打来，原有计划就完全泡汤了。后来是忙于部门间交流，经常会被各种流程所累，折腾来折腾去，年终总结的时候，发现这一年又白过了，空悲切。

一个企业随着业务增加，各类工作就会显得非常杂乱，此时大家特容易出现疲于奔命的状况。为了解决这个问题，常采取的策略是将人员分成多个部门，如销售、研发、测试、生产、工程服务、技术支持等，但紧随其后的各部门之间的玻璃墙又会将人折腾的疲惫不堪。

人多了必须分部门，但部门多了交流就会困难，这种现象好像无解，别人有没有好的策略呢/p>

我所在的项目组因为人多，也分为多个部门，仅我接触到的就有需求管理、研发、平台、测试、生产、品质等诸多部门，但在具体做产品的时候，又感觉不像我们传统意义上的部门。如果有一个项目时，会从各部门挑选人员组成临时项目组，由项目负责人统一管理调度，项目结束后人员在回归原部门。

我当初参与的一个项目组，其中竟然包含一个生产工人。该产品在样机和小批量供货阶段，都是他一个人在负责生产，经常是推着一个小推车，一道道的工序打磨。后来这个产品结项后，这个人会自动回归生产部门，如何构建有效的生产指导文件，如何增加流水线以满足批量生产计划，如何同其他产品复用生产线等等诸多细节，都是生产部门份内的工作，不需要项目经理操心。

生产部门如此，其他部门也大都类似，如对外测试部门，会随着需求分析、产品架构设计等环节，自然而然的构建有效的测试案例，同时为了一些自动化测试，也会要求产品中增加特定的支撑功能。

这种工作模式，对个人成长非常有帮助，每个人都会获得两方面的成长，不仅在各部门接受专业化的训练，同时在项目组又可以更好的理解市场和产品，培养全局观。如带我的那个规约工程师，他经常会同时参与多个产品设计和研发。这种经历不仅让他理解规约应用在多个产品中的细微差异，而且也能以更专业的方式构建高复用的规约模块。

而且，这种工作模式，会大幅度减少各部门之间的推诿扯皮，甚至各部门之间根本不需要一些鸡同鸭讲的指导文档，实际上，研发人员压根写不出有效的生产指导文档的。

至此，我看到了一种有序的工作模式，平时看似散沙，但一旦有具体的项目任务，又能快速的聚集起来，成功的破解了我最初面对的各种困局。

1.3.6 看到就是一种力量

可能是因为自己曾经的“痛苦”经历，又或是自己一直在琢磨如何更有效的工作，短短一年左右的联合研发经历，让我在本职工作之外，狠狠的开阔了一次视野。

记得那些日子，因为常请教很多本质工作之外的事情，搞的两个翻译经常会很不耐烦，经常需要小心的陪着不是。虽然因为合资的原因，对方没法阻扰我们参与其中，但很多时候都会防着一手。对方喜欢拉着我们参观各部门、樱花树下喝小酒，但一旦涉及具体工作，就会谨慎得多。如我一直惊奇他们仅使用12位AD芯片，但精度竟然超过了我们使用16位AD芯片的产品，可惜最后别说弄明白了，甚至连相关部门的工程师都没见到一枚。

即使如此，我感觉这次联合研发的经历，也让我受益匪浅。自己一直在工控产品领域摸爬滚打，因为工作内容类似，很多东东都仅仅是一层窗户纸，看到别人怎么做，我很容易能想清楚为何要这样做。

别人能，我为什么不能了技术方面，这次经历给我最大的帮助就是信心的增强，而“看到”真真切切给的给我了力量。

带着您遨游一圈，您感受到那种力量了吗/p>

返回目录
——————————————

我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如需最新版PDF电子书，或期望深入交流，可加个人微信nzn_xiaomaer交流，需备注“异维”二字。