1.4 我的漫漫探索路

1.4.1 看到是一粒“种子”

短短的联合研发结束后，我又回到了自己原来的部门，还有原先的工作模式。不知大家是否会有这样的体会，如果一直呆在大城市的雾霾中，可能慢慢就迟钝了，但到风景秀丽的地方度两天假，感受一下清澈的世界，回来后立马会有诸多不适应，而这恰恰就是我当时的真实内心感觉。

在东芝G2项目组的这段经历，仅仅是让我看到了一些表面东西，不仅不够全面，而且不够深入。东芝本部的人好像刻意防备着我们，很多话题甚至会被日方翻译直接给挡住，压根不给你翻译。即使看到了一些表面东西，也很难模仿，如G2平台基于FB的复用机制，需要复杂的配置软件支撑，压根不是我们这种小团队可以承担的。在该过程中，我能做的仅仅是将自己看到的各种东东记录下来，然后……，基本上就没有然后了。

同时，我自己部门负责的产品经过多年的迭代，已经固化了，而且大多同公司管理体系深度融合，牵一发而动全身，根本无从下手。各种高复用的软件模块是很好，但需要复杂的支撑环境，如前面描述过的104规约复用策略，想想都难以执行，那么多支撑模块谁来做。大家平时的工作都忙死了，即使有空，如果你胆敢安排和当前工作“无关”的事情，估计也会被领导骂死吧！

内外夹击，让我非常的苦恼，有一种抱着金碗要饭吃的挫败感。网络上经常有人感叹，知道了很多道理，却依然过不好这一生。看到和做到，虽然只有一字之差，但却似有天壤之别。我虽满心不甘，但如无意外，自己估计也会像祥林嫂一般，在喋喋不休的埋怨中平庸下去。

所幸，天无绝人之路。我们公司的生产线改造，邀请了一个精通丰田生产模式的专家，我又恰好感兴趣去旁听了几场。刹那间，我突然有了一种明悟，虽然丰田是造汽车的，而G2项目组是搞嵌入式软件的，但很多策略透过表象隐隐约约有相通之处。

如丰田生产模式中很重要的“单件流”思想，是为了防止批量零部件生产出现问题时造成浪费，同时也用后一道工序同零部件生产过程构成闭环，这不和G2项目组中强调“价值流”有点殊途同归的味道吗？再比如丰田的拉灯机制，生产线员工检测到问题后可以通过拉灯暂停整个生产线。实际上拉灯机制不是重点，拉灯之后的快速应对才是关键，需要一个支撑团队快速解决问题，这好像同G2平台有一批优秀员工持续完成审核和产品集成有异曲同工之妙。很多人都听过丰田的5S制度，实际上5S是一种标准化行为，不仅可以规范员工的操作行为，而且便于审核和发现问题。类似于丰田，我在东芝也经历过大量的标准化行为，甚至震惊于大规模的员工流动行为。

记得当时，我快速的买了一套讲解丰田模式的书籍，然后开始慢慢感觉到当初自己胡乱记录的各种零碎片段连成了线，织成了网。再然后，我发现丰田模式的源头来源于美国戴明博士的质量管理体系，因此我顺势又胡乱的阅读了一些戴明的著作。当下工作依旧在无聊地持续着，但因为这些“杂书”，我内心好似开始孕育了一枚种子。

1.4.2 审核机制

有段时间，我身旁多出一个新招来小伙，因为他的领导“太忙”没时间管他，整日有点无所事事。我看小伙挺好学的，于心不忍，经常指导他一下，顺手将自己正在写的一个软件拷给他参考。

一段时间后，小伙程序看的差不多了。我内心怦然一动，免费的资源不能浪费啊，因此“善意”的指点，程序仅仅看是不够的，最好能动手写一写，实际参与一下，你才能真正的学到，不然都是过眼云烟。道貌岸然的说完这段冠冕堂皇的话后，我将一个自己一直想做但一直没时间做的软件模块推给了这个小伙。

不久，小伙做完了。我打开程序一看，虽然有一些考虑不周之处，但还算是很漂亮的完成了任务。为了偷懒，也为了让这段程序看起来像自己写的，我进一步要求小伙将这段程序格式修改的和周边程序一致。

记得当时，我们项目组都是每人负责一块代码，大家写代码也基本是个人英雄主义，我自己的代码哪有什么约定的编程规范，经常是今天一时兴起模仿这个高手，明天就忘到九霄云外了，前后不一致处比比皆是。但即使如此，小伙也给我模仿了个八八九九，乍一看，和自己写的也差不多。

一次意外，换来了一份欣喜，也让我内心开始活络起来。从此，我在公司里以好带人而闻名，频繁奔波于招聘现场，甚至还挂了一个优秀导师的称号。当然，与此同时，很多新入职的员工，甚至一些还没正式入职的实习生都被我下了黑手，每个人都多多少少顺带着贡献了一些代码。

在这个过程中，最典型的莫过于维护软件了。从公司的角度看，维护软件是非卖品，因此几乎不会额外安排人力和时间，如果看到你周报在写维护软件，下周立马就会给你安排新任务了。但是从整个产品角度考虑，维护软件又是必需品，很多调试、测试甚至车间生产工作都需要维护软件配合。有了维护软件，感觉产品研发才闭环了。

一开始，我仅仅是简单弄了一个小软件用于应付调试，但这活一旦揽上后就麻烦不断，各种需求层出不穷经常让我疲于奔命。我在想，是否可以充分利用新人资源来完善维护软件呢？

为了适应这种偷懒模式，我开始尝试重构维护软件。首先将维护软件整体架构重新进行了优化（本书后续章节会详细介绍），以便于多个新人可以分别完成不同的软件模块，我仅需要简单合并就好。然后开始形成统一的编程规范，并形成文档，指导新人养成好的编程习惯，好让别人写的代码看起来像我写的，也好邀功。

时间的力量是无穷的，没多久，我的维护软件就快速充盈起来，甚至有空做一些好玩的稀奇古怪的功能。更重要的是，在这个过程中，我体验到一种全新的工作方式：我只要能做到思考整体架构，高效辅导新人，审核并合并代码，一个新的软件就构建完毕了。

尝到甜头后，我开始慢慢的在自己团队内部推行这种工作模式。一开始并不容易，和新人要求编程规范还相对容易，很多老人会很抵触，你只能慢慢的去影响大家。岁月如梭，不经意间，我发现自己的工作开始“爽”了起来，思考产品整体架构和各模块接口，写一堆空函数后的代码就被我甩给了团队其他成员，别人写一周的代码我熟练后可能仅需要审核半天，然后就可以将其成果霸占了，还有时间去学习，去思考，去抬头看看远方的路。

细细思量“代码审核机制”这段奇妙的经历，虽然源于自己偷懒的目的，做法有点野，但难道不和跨国企业内部重要的价值流概念很相似吗？后期，不仅我个人工作效率提升了很多，而且也真正帮助到了新人，大家反而都很感激。

从此，代码审核机制成为我成长的第一块垫脚石，更进一步，我发现代码审核机制哪止“偷懒”这一点好处。如我以前总发愁团队不好带，随便离职一个人，就会坍塌一大块代码，搞得大家很狼狈。但通过代码审核策略，可以很有效的规避这一问题。在我眼中，代码审核机制，不仅可以将很多单人有效的扭结为一个高效的团队，更是新人培养、老人提升、白盒测试、知识库积累、工作标准化等诸多工作的有效手段和基石。

1.4.3 配置软件

工控产品因为应用领域差异较大，经常有系列化的需求，但这也给产品研发带来了困惑。如产品A中有一种“设定值”的数据结构，用于用户参数设定，属性主要包括名称，描述，数据类型，默认值，最大值，最小值等。碰到这类数据结构，我们很自然的会想到使用C语言结构数组来描述，如下代码示例。基于这样的数据结构，程序实现起来会容易很多，即使增加或减少一些设定值时，仅需要修改数据结构即可，不需要该动程序主体。

/* 定值属性描述结构 */
const TAPISettingProp g_apiSettingProp[] = {
	{
		“CT接线方式”, 0, 2, 8, 0, 2,
		0.000f, 1.000f, 0.000f,
		&SET_uCTLineType, (TAPICoeffProp*)&g_apiCoefProp[19]
	},
	{
		“PT接线方式”, 0, 2, 8, 2, 2,
		0.000f, 1.000f, 0.000f,
		&SET_uPTLineType, (TAPICoeffProp*)&g_apiCoefProp[19]
	},
	……
};

现在假设产品B也需要这种“设定值”怎么办呢？我们容易想到的最简单策略是将上述结构单独移到一个文件中，然后针对每个产品弄一个特定描述文件。

现在假设要拓展海外业务，领导要求你赶快弄一个英文版本该怎么办呢？没法子，赶快在弄一个特定描述文件。

碰上有个性的客户，他们坚持一些习惯称谓，你被迫又需要改一套。

……

这也太苦逼了，现场随便来点需求，我就需要修改并下发程序。控制程序下发流程的那帮大爷可不管你是否仅修改了数据结构，各种流程一个都不能少。有没有办法将这部分工作甩出去，让工程人员现场就可以修改呢。被逼无奈，我开始对上述数据结构进行参数化改造，将数据模型提炼组织起来，在额外写一个小程序生成参数。从此以后，这类问题工程现场想怎么改就怎么改，我顶多写个说明文档，在费点口舌给工程人员讲解几轮，然后就再也不会因为改个名称或浮点小数点位数等琐事而整日下发程序了，幸福的日子开始回归了。

我写的超级简陋的参数生成软件如下图所示：

我承认，跨国企业为了做到代码高复用率，需要很复杂的配置软件，我做不来。但细细思量这个小软件的奇妙经历，我发现虽然自己的做法简陋了很多，但难道不似曾相识吗？

1.4.4 收获与反思

反思两个简单的例子，我发现自己有时候已经走了很远，只是自己懵懵懂懂无意识而已。那么现在我已经看到了方向，如果能多一点主动行为，可否可踏上这条架构师之路呢？

走上这条路，我个人的能力有限，仅靠个人肯定是不行的，而且也势必会影响到很多人的工作方式。额外，同维护软件类似，平台化一开始肯定需要做很多基础性工作，初期也不容易见效。我如果和领导直说，估计会被直接拍死吧。有什么好的策略呢？

在公司经常会碰到各种奇葩的事情，领导如意识到内部管理混乱时，经常会引入外部各种高大上管理体系，不仅昂贵，而且经常将原有的工作模式弄得支离破碎，直到最终难以为继。我个人可能因为特定的工作经历吧，比较反感这种做法，不喜欢信息技术部门将某种“新”技术强行推给一线设计或制造部门，而是喜欢那种由内而外，由最底层需求驱动并借力新技术的模式。

如何将我看到的好的东东慢慢融入已有的产品研发体系呢？最好的驱动方式又是什么呢？我是一个懒人，特讨厌各种低层次重复的工作。我估计大家都差不多吧，偷懒，是非常契合人性的需求。在一次，我祭出了“偷懒”这一绝招。

首先是添油加醋的同团队内成员分享我在维护软件中偷懒的光辉经历，然后发出诘问：“你是愿意一辈子重复这些无聊的代码呢，还是愿意走上架构师之路”。很快，大家形成了统一的共识，团队内部形成了统一的代码规范，大家都开始有意识的锻炼指导新人和代码审核的能力。

刚开始可能会比较混乱一些，但没多久，我发现自己竟然开始有空余时间了。跨国企业做产品时，为了适应不同区域的需求，经常会构建第二层开发环境，其中最重要的模块就是类脚本模块，我开始花精力攻克这个软件模块。

在这之前，研发团队的很大一部分工作是做各种现场特殊版本，时间紧，要求变态，还经常将我的团队人员抽调到现场不放回来（研发人员比工程人员好用，而且免费，v_v），弄得大家苦不堪言。但自从有了脚本模块后，我开始有一种特“爽”的感觉。现场工程人员打电话来，用户需要一个特殊要求，我经常直接电话指导，巴拉巴拉半个小时后，一切搞定。今天效率太高了，要不休息休息，泡一杯茶，品着茶香，怎一个“爽”字了得。

从此以后，我们团队好似玩起了开挂模式，以前弄几款产品就累的半死，现在不小心已经维护了一堆产品了。当然，新情况也带来了新问题，各产品之间代码开始慢慢混乱起来，维护工作量又开始慢慢增加了。

为了进一步偷懒，我开始尝试整合这些乱七八糟的产品代码。先易后难，先从大家都用的公共辅助函数开刀，慢慢的在啃那些乱七八糟耦合的程序模块。

◇◇◇

为了偷懒，我在勤奋的折腾着，而每次折腾，都给我意外的惊喜，让我更加坚定的偷懒。时光荏苒，岁月如梭，转瞬八载过去了，惊奇的事情开始发生了，原先在我眼中跨国巨头那些不可思议的做法，我们竟然模仿了一个似模像样。

这儿和大家分享一些我们取得的成绩：

1. 构建出平台、产品、工程三层研发体系
   前文提及我很欣赏跨国公司这套做法，但跨国公司那套基于FB的代码复用机制过于复杂，很难模仿。在实践中，我们通过加强各模块的api抽象，利用参数化和脚本支撑模块，竟然也让代码复用率大幅度提升，新产品的代码复用率基本都超过了70%。记得有一次，同一个公司竞争某光伏项目，其关键在于谁能在三周之内研发出一款满足特定需求的新产品，最后，另一家厂家退缩了，因为他们无论如何也完不成。因为极高的代码复用率，我们在约定时间内将所需产品折腾出来了，内心成就感油然而生。

2. 软件体系架构
   大家还记得我前文提及，成为架构师是我的奋斗目标之一吗？刚开始的软件复用基本谈不上什么架构设计，但随着持续迭代演化，很多巧妙的设计理念开始层出不穷，我的架构设计能力也在潜移默化中提升了。如为了将将无数个复杂的模块有机的组织在一起，我设计了静态程序架构；如为了让程序既可以在前后台系统运行，又可以基于OS运行，我设计了程序动态执行框架；如为了适应产品组件越来越多内部交换繁杂的情况，我设计了基于can的分布式架构……。最后，一点一滴的，我好似搭起了一座颇具规模的大厦。

3. 持续的质量控制提升
   为了将自己从救火队员的身份中解救出来，我们在反复折腾尝试中，最终提炼出了三个非常有效的策略：代码审查机制、集成测试机制、在程序框架中内建异常检测及主动防御机制。某一次，公司领导找到我，让给大家分享一下，为何我负责的产品能够做到零返修。此时，我才意识到自己不小心已经走出去了一大步。实际上哪儿是零返修，仅仅是在用户还没有暴怒之前我们已经将所有问题给解决了，大家感觉不到而已。而这个过程中，各种异常或边界判断机制帮了大忙。

4. 高效适用的文档体系
   没有文档的产品是不完备的，但写文档又会加重大家的负担，且很多时候劳而不功，大家抵触情绪会很强烈。为了解决这个问题，我在反复尝试中，形成了一套高效实用的文档体系，包括：以图表为主要表现形式的架构设计文档，以A4纸为主要形式的接口设计文档，强调迭代和闭环集成测试用例文档，产品说明书，服务于新人成长和代码审核的知识库文档。除此之外，如果人数少，现地现物通过周例会就能搞定，人数多时可以增加一定量的工作日志文档。在这套体系中所有的文档都是必须项，同时必要的文档项目团队也会认真对待，最终构建出一套高效适用的文档体系。

5. 如臂使指的团队建设
   因常年从事具体技术工作，团队建设一直是我的弱项，内心甚至有点抵触情绪。但我又需要带着小伙伴们一起做产品赶项目，新人需要入职培训，老人也需要职场提升，怎么办呢？为了构建那种如臂使指的团队，我先后提炼了最小必要知识、代码审核、A4纸接口设计审核、知识库等诸多工具，让团队中每个人的成长都可视化。水滴石穿，在我以身作则的带头作用下，整个团队最终成功长成了一个积极的学习型团队。

慢慢的，我发现自己对工作的感觉完全变了，好像自己真的成了一名架构师，统领着千军万马，即使面对纷繁复杂的产品，都可以从容面对。您期望这样的自己吗？

反思自己的整个经历有几个关键的点，有起始阶段的“看到”，有以“代码审核”为抓手的起步阶段，有模块接口提炼为侧重点的攻城略地，也有最后以“复用”为抓手的架构设计收尾。我个人的成长经历有机缘巧合的因素，不容易复制，但是否可以将这一过程整理成他人成长的台阶呢？我反复思考迭代后整理如下：

1. “看到”是一粒种子
   如果当初没有在G2平台组的一段经历，我可能也不会有后续的一系列折腾。知道自己的不足和别人的优秀，可能不会有立竿见影的效果，但会在潜移默化中影响你以后工作中的点点滴滴。因此在做新人培训时，我喜欢先在大家头脑中构建一个虚拟的优秀的架构思想，不仅期望在大家心中埋下一粒种子，而且有助于全局性指导后期工作。

2. 快速入职
   新人培训是架构师的基本职责之一，甚至需要从架构的角度去考虑，新人入职是培训体系的起点。从学校到职场，从单一专业跨越到完整产品思维，对很多新人都是一个痛苦的经历。我们没有时间让新人以大学上课的方式逐项学习，而是需要快速入门。此时，需要架构师提炼出产品需要的各种知识点和最常用的技能，并构建最小入职培训体系，以帮助新人快速上手。

3. 审核和团队
   代码审核机制是最有效的从个人英雄模式跨越到团队模式的策略，通过审核机制可以让整个团队有效凝聚起来。不仅如此，代码审核机制还是新人培养、老人提升、白盒测试、知识库积累、工作标准化等诸多工作的有效手段。

4. 接口抽象
   一开始空谈架构，反而会导致工作阻力很大，反而难以执行。此时，最好的策略是侧重于优化各模块的接口，从简单到复杂，慢慢的大家就能嗅到架构的味道了。

5. 可复用架构
   单纯的接口提炼，仅能做到有限程度的代码隔离，不小心各模块又紧紧耦合在一起了，此时就需要产品层次的一些架构设计了。如何进行架构设计，“复用”是我发现的一个很好的抓手，只要持续迭代下去，优秀的架构会自然的长出来的。

6. 质量和团队
   做出产品容易，但做出好产品难，职场上很多工程师的大部分时间不是在查找各种bug，就是在解决现场工程问题。很遗憾的是，产品质量问题的解药从来不是测试，而是管理，需要有效的团队协作才能提升产品质量。戴明博士的全面质量管理体系，将质量、管理和团队完美融合在了一起，成为我们跨越这一步很好的切入点。

或许还烙有东芝或丰田的影子，但我实际上是构建出了一套全新的工业嵌入式产品研发理念。不同于东芝G2平台那种大规模协作，这套理念相对小巧接地气，适合小规模研发团队。又因为背后隐含着一个人从入职到成长为架构师的全过程，也便于大家学习。逐级拾阶而上，个人会完成从入职到架构师的蜕变，企业自然也会从传统的拷贝粘贴研发模式跨越到平台化研发模式。

2018年，中兴事件爆发，作为一名工程师的我，那段时间明明不关我啥事，但内心特别难受焦虑。我喜欢逛各种技术论坛，知道国内绝大多数小企业和个人都处在非常低级的层次上，又因为特定的工作经历，让我深刻理解国外巨头和国内中小企业之间的巨大差距。如果一家公司还是传统的研发模式，根本不可能培养出各细分专业人才和架构师的，注定只能做一些低层次的产品，是没有办法同那些巨头竞争的。

因为中兴事件的触动，我开始思考如何将自己的工作经历及思考分享给大家。多年的带人经历，我发现对新人来说，逐级拾阶而上可能是最好的策略了，因此这也成为本书的组织结构。用文字将自己的工作经验整理出来，不仅可能会帮助到一些人一些团队，更是一次体系化思考的过程，是和自己的一次深度对话。

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

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