一次咨询活动，同一朋友交流基于复用的架构设计理念时，他说：“你讲的那个很好，但离我们现状有点远。我现在每天要编码、要开会、要出差、要交流、要带人、要流程，招个能干的人可难了，而刚做顺手的就想跑，留一堆代码让我擦屁股……”一段话不知道出了多少一线工程师的心酸，我们又有多少人是整日忙的晕头转向而最后却又碌碌无为。
额外，这段话也道出了一个关键点，我们的技能提升是分层次的，跨层次对话，如和饥饿的人交流饮食品味一般，适得其反。从入职到架构师，我将整个嵌入式成长之路分为了多个层次：入职——团队——抽象——复用——架构——标准化。现在，我们迈过了入职陷阱，开始进入团队构建层次。
在继续之前，我想让大家做一个简单推理，设想一下：如果你是我那个朋友，在这种工作状态下再继续十年，会是什么样子呢？记不得在哪儿摘录的一段警世危言，或许会带着我们穿越时间。
“一名优秀工程师的成长需要时间
但仅仅靠时间堆砌，却难以培养出一名优秀的工程师
让人无奈的是，国内工程师的成长环境恶劣
导致所谓的十年工作经验，仅仅是十年工作经历而已
或悲催的转行，或无奈的继续，不小心陷入中年危机
然而上有老，下有小…… ”
朋友们，抬眼往四周看一看吧，那些早腻烦工作混日子的人，那些被迫转型但举步维艰的人，甚至是那些身陷工作经济困局而跳楼的人，比比皆是。如果你不试着改变，你就会成为下一个。
如何走出这个困局呢？软件工程的研究成果早就告诉我们答案，通过代码审核机制，完成从个人到团队的锐变。
代码审核，英文名为code review，是指他人对计算机源码的审查，是软件编码（code）和提交（commit）之间的一个重要流程，用于提升软件质量。
我花了很大功夫，也走了很多弯路，才在自己团队内部形成有效的代码审核习惯。但是，当我跌跌撞撞站到了彼岸，我惊喜的发现，所有的辛苦都是值得的。
大家可能会有这样的体会，工作经验丰富到一定程度后，大部分工作可以立即排出个一二三来，也知道哪些点容易出错，但即使如此，如果所有事都亲力亲为，依然需要花不少时间。控制好关键节点，交由团队其他人并进行审核，其结果等价于自己在做。此时，好似所有的人都成为你的臂膀，那种如臂使指的感觉，或许只有亲历过来能真正体会。
因为所有的代码都处在动态审核中，某工程师即使提出离职，我一般能在两到三天内完成工作交接，再也不会出现以前那种因某人离开而塌掉一块业务的被动局面状态。
稀缺会引发进一步的稀缺，当你忙的一塌糊涂时，你很难有机会去尝试如何提升工作效率。审核机制，给我带来最大的价值就是时间开始适度富余了，我不仅能出色的完成了各项本职工作，而且开始有时间去思考、总结、提升，这些都有助于进一步提升工作效率。
因此，职场的朋友们，您哪怕爬，也要爬过这一层境界，然后借助团队的力量，铺就你成长的阶梯。
◇◇◇
代码审核，直白一点就是阅读别人的代码吗！相信大家都有读他人代码的痛苦经历，也经常会埋怨弄懂这段垃圾代码，还不如重写一遍呢。因此，推行代码审核机制，从来都是知易行难的一件事。
为了让代码异于阅读，制定编程规范是首当其冲的问题。统一的编程规范，至少会让别人的代码看起来像自己的代码，因此，各公司都制定了各种五花八门的编程规范。但即使是这么一点点小小的要求，推行起来也阻力重重，大多情况下最后都会不了了之。
起步艰难，形成有效的代码审核机制更是不易，为何会这样呢？又怎么办呢？
我刚参加工作时，接触过一款产品，其架构设计挺优秀的，甚至可以说是我初学架构设计的奠基石，但该产品最后却走向了被淘汰的命运。
为何会出现这样的现象，或许代码中的一段注释会给你答案：我今生最倒霉的事情就是接了这段代码，这段注释后面还附有很多条血泪史。
在《clean code》一书中，bob大叔认为在代码阅读过程中人们说脏话的频率是衡量代码质量的唯一标准。同理，《编写可读代码的艺术》一书中，作者也提到程序员之间的相互尊重体现在他的代码中，也能体现他对工作的尊重。
无数的血泪史告诉我们，代码最重要的读者不是电脑，不是解释器，不是编译器，是人，是我们的同事，是三个月后的我们自己。代码不是用复杂技巧表现自己多牛叉的，而是需要让他人快速理解、轻松维护、容易扩展，这样才配得上一个专业程序员的情怀。
道理没错，但我们在执行方面却举步维艰。
记得领导让我开始整理编程规范时，作为一个典型的外向型IT男，有表现机会，当然跃跃试试了。因此我开始下功夫，从网上找了MISRA规范，华为编程规范等，然后将其中的精华（当时能力有限，基本看到的都是精华）都找出来，然后汇聚成了一本超百页洋洋洒洒的C编程规范第一版。
其后的结果估计大家应该能猜到了，我被炮轰的体无完肤了。想想也是，几百条的规范不说执行，仅记忆都是一件不可能的事情，再说即使执行了，又如何审核呢。
初次尝试就以这样的方式没了下文，但整理规范这件事本身对我还是有影响的，自己在写代码时，潜移默化的总是会用到一些，再然后，就潜移默化的影响到了身旁的人，影响到了自己所在的项目组。一段时间之后，一组员在阅读其他组代码时，发现别人的代码已没法读了。暮然回首，原来我们已在灯光阑珊处。
不经意间的成功让我开始深入思考编码规范如何推广的问题。我思考了良久，得出两个结论。
第一点：再多的编程规范，再多的教条，也赶不上一段优秀代码。每个人都有追逐优雅的天性，当好东西都被拿来占为己有时，编程规范自然推广下去了。
这一条，实际上慢慢的成为了我后来的工作准则之一。连自己都做不到的事情，不要去要求别人。将自己的代码交由别人审核，很快就能带出多个自己。
第二点：初期推广，需要保证大家半小时的注意力能够听完一遍。
我看过一本讲解脑科学的书籍，说人脑记忆力非常有限的，3条最佳，5条尚可，超过7条就开始左脑进右脑出了，而且半个小时内，大家也顶多学习5条。因此，我发狠，原先300条的编程规范，一定、必须、无论如何也要压缩到五条。
反复的割肉放血，第N版的编程规范终于出炉了，依次如下：
- 云深不知处——文件全局观
- 灭绝裹脚布——编码细节观
- 代码如天书——约定注释
- 相见不相识——统一名称
- 懒人大法——借助工具
因为其中第五条是探讨如何通过工具辅助实现前四条的，都不好算作编程规范了，因此，我们团队内部经常戏称为四条半编程规范。后续，我会用连续的五篇内容分别介绍每条规范的来龙去脉。
——————————————
我是小马儿，一个渴望良知与灵魂的嵌入式软件工程师，欢迎您的陪伴与同行，如感兴趣可加个人微信号nzn_xiaomaer交流，需备注“异维”二字。
