一次咨询活动，同一朋友交流基于复用的架构设计理念时，他说：“你讲的那个很好，但离我们现状有点远。我现在每天要编码、要开会、要出差、要交流、要带人、要流程，招个能干的人可难了，而刚做顺手的就想跑，留一堆代码让我擦屁股……”一段话不知道出了多少一线工程师的心酸，我们又有多少人是整日忙的晕头转向而最后却又碌碌无为。

额外，这段话也道出了一个关键点，我们的技能提升是分层次的，跨层次对话，如和饥饿的人交流饮食品味一般，适得其反。从入职到架构师，我将整个嵌入式成长之路分为了多个层次：入职——团队——抽象——复用——架构——标准化。现在，我们迈过了入职陷阱，开始进入团队构建层次。

在继续之前，我想让大家做一个简单推理，设想一下：如果你是我那个朋友，在这种工作状态下再继续十年，会是什么样子呢不得在哪儿摘录的一段警世危言，或许会带着我们穿越时间。

“一名优秀工程师的成长需要时间
但仅仅靠时间堆砌，却难以培养出一名优秀的工程师
让人无奈的是，国内工程师的成长环境恶劣
导致所谓的十年工作经验，仅仅是十年工作经历而已
或悲催的转行，或无奈的继续，不小心陷入中年危机
然而上有老，下有小…… ”

朋友们，抬眼往四周看一看吧，那些早腻烦工作混日子的人，那些被迫转型但举步维艰的人，甚至是那些身陷工作经济困局而跳楼的人，比比皆是。如果你不试着改变，你就会成为下一个。

因此，职场的朋友们，您哪怕爬，也要爬过这一层境界，然后借助团队的力量，铺就你成长的阶梯。

◇◇◇

为了让代码异于阅读，制定编程规范是首当其冲的问题。统一的编程规范，至少会让别人的代码看起来像自己的代码，因此，各公司都制定了各种五花八门的编程规范。但即使是这么一点点小小的要求，推行起来也阻力重重，大多情况下最后都会不了了之。

我刚参加工作时，接触过一款产品，其架构设计挺优秀的，甚至可以说是我初学架构设计的奠基石，但该产品最后却走向了被淘汰的命运。

为何会出现这样的现象，或许代码中的一段注释会给你答案：我今生最倒霉的事情就是接了这段代码，这段注释后面还附有很多条血泪史。

无数的血泪史告诉我们，代码最重要的读者不是电脑，不是解释器，不是编译器，是人，是我们的同事，是三个月后的我们自己。代码不是用复杂技巧表现自己多牛叉的，而是需要让他人快速理解、轻松维护、容易扩展，这样才配得上一个专业程序员的情怀。

道理没错，但我们在执行方面却举步维艰。

记得领导让我开始整理编程规范时，作为一个典型的外向型IT男，有表现机会，当然跃跃试试了。因此我开始下功夫，从 上找了MISRA规范，华为编程规范等，然后将其中的精华（当时能力有限，基本看到的都是精华）都找出来，然后汇聚成了一本超百页洋洋洒洒的C编程规范第一版。

初次尝试就以这样的方式没了下文，但整理规范这件事本身对我还是有影响的，自己在写代码时，潜移默化的总是会用到一些，再然后，就潜移默化的影响到了身旁的人，影响到了自己所在的项目组。一段时间之后，一组员在阅读其他组代码时，发现别人的代码已没法读了。暮然回首，原来我们已在灯光阑珊处。

不经意间的成功让我开始深入思考编码规范如何推广的问题。我思考了良久，得出两个结论。

第一点：再多的编程规范，再多的教条，也赶不上一段优秀代码。每个人都有追逐优雅的天性，当好东西都被拿来占为己有时，编程规范自然推广下去了。

第二点：初期推广，需要保证大家半小时的注意力能够听完一遍。

我看过一本讲解脑科学的书籍，说人脑记忆力非常有限的，3条最佳，5条尚可，超过7条就开始左脑进右脑出了，而且半个小时内，大家也顶多学习5条。因此，我发狠，原先300条的编程规范，一定、必须、无论如何也要压缩到五条。

反复的割肉放血，第N版的编程规范终于出炉了，依次如下：
1. 云深不知处——文件全局观
2. 灭绝裹脚布——编码细节观
3. 代码如天书——约定注释
4. 相见不相识——统一名称
5. 懒人大法——借助工具

因为其中第五条是探讨如何通过工具辅助实现前四条的，都不好算作编程规范了，因此，我们团队内部经常戏称为四条半编程规范。后续，我会用连续的五篇内容分别介绍每条规范的来龙去脉。

返回目录

——————————————

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

文章知识点与官方知识档案匹配，可进一步学习相关知识C技能树首页概览113322 人正在系统学习中