---

之所以对这个问题感兴趣是因为在知乎关注的一位清华核工厂大佬转码之后去了菊厂之后，经常说自己在刷LeetCode，并且马上要考试了，当时就非常纳闷，工作了还要考试？

最近看了一篇文章 https://www.cnblogs.com/shoufeng/p/14322931.html

才知道了华为可信专业级认证是什么。

华为在推动技术人员的可信认证，算是一项安全合规的工作。
专业级有哪些考试呢？共有四门：

科目一：上级编程，对比力扣2道中等、1道困难；
科目二：编程知识与应用，考察基础的编程语言知识等；
科目三：安全编程、质量、隐私，还有开发者测试等；
科目四：重构知识，包括设计模式、代码重构等。

科目一是两道偏难的中等和一道困难，这个难度还是相当大的，基本上不认真刷一个月题是做不出来的。

科二、科三、科四到还好，主要是了解一下在代码之上的一些东西。

这里也有一篇将通过可信考试之后感悟的文章：https://xinsheng.huawei.com/cn/index.php?app=forum&mod=Detail&act=index&id=5156713

---

曾几何时，可信成了华为软件工程师口口相传的热词，它出现在罗马广场心声社区上，出现在我们的技术规范要求中，出现在我们的编码里，同样出现在让人头疼的考试里……

回首过去两年的可信历程，从被迫接受，到半信半疑，到潜移默化，可信慢慢地融入到开发的流程、代码和意识中。今天，我来说说，我与可信之间的故事……

---

你好，可信

“今天晚上会议的主题是：可信。”明亮的会议室灯光下，主管敲着黑板说的话。

“最重要的是，大家先背下可信的六大特性：安全(security)，安全(safety)，韧性(resilience)，隐私性(Privacy)，可靠性(Reliability)，可用性(Availability)……”

“总之，我们的产品就是要做到让客户感到充满安全感，让对手感到绝望，让攻击者无路可走，在经受层层打击下，还有自我恢复的能力。”这是主管的总结发言。

这是我印象中第一次接触可信这个概念，谈不上印象深刻，就是知道我们要干一件更牛的事，我们的产品已经不满足于功能的实现了，还要像“超人”的钢铁之躯一样强大，顺带的，要背下六大特性。

当时，某国某日报突然发布了一篇文章，号称使用先进的二进制工具，对华为各产品线发布的众多二进制程序包进行了逆向扫描分析（就如同拿到市面上一瓶新款可乐，通过品尝、化验、观察反推其配方比例，还推测其使用的某种原料可能有问题），最终结论是华为产品安全性远低于友商。

对于这种质疑文章，我们要从技术上，逐一进行分析。于是，以可信专家牵头，产品各领域投入了精兵强将，对文章中列举的各项数据进行了严谨分析，我也有幸加入了“战斗”。

在封闭作战室，经过一周的反复代码分析、统计、检查、阅读，我的心态慢慢地发生了变化。比如，一些老版本的内存操作函数接口参数上没有约束，新手在粗心的情况下是可输入错误的参数，进而造成潜在的安全风险（虽然检查后发现实际并没有这样的错误使用），这是存在改进空间的。令人欣慰的是，我们新版本的函数从接口上约束使用者无法输入错误参数，并统一使用公司的安全函数库，避免了各部门重复“造轮子”。

另外引起我思考的是，第三方机构在没有我司源代码的情况下，都可以通过逆向技术，挖掘出我们多个可能潜在的安全突破口，我们真做到“可信”了吗？

他山之石，可以攻玉。日报事件引起我们对“可信”的反思，比内部100个发文更加震撼，并让我们深刻意识到：在这个技术飞速发展的今天，拿到二进制执行程序，就相当于拿到源代码。我们必须抱着开源的心态，构建我们代码的可信性。

---

刷新“可信”认知

安全实验室有一批专家的工作就是对产品源代码以超过业界标准的严苛要求，进行“挖地三尺”的挑战，提出让人感到“吹毛求疵”的整改任务，以这样一种特殊方式不断提升产品品质。有一天我收到一个印象很深刻的任务。

“这是我们内部通信的消息处理函数，这里有一堆数值校验还不够么，还要进行全面的安全校验吗？是不是有点过了？这个东西对外没有物理通道接口，非标准的协议，对方是如何知道我们的通信格式？”拿到那个任务的时候，我一开始是挺不以为然的，这种感觉就像是在一个层层保护、守备森严的堡垒中的两个人之间使用一种内部语言交谈前，还要先检查下对方是否“安全”了

最后，安全专家说服了我，他列举了两个事实：第一，安全实验室已证实在某些极端条件下可通过下层挂接设备攻破侵入上级设备的子系统，第二，在这个时代，拿到二进制程序就相当于拿到源代码。所以，从理论上，破坏者是可以侵入并且构造让系统异常的内部通信消息报文的。

这再一次刷新了我对“安全可信”的认知，原来，我们以前认为的安全，并不是真正持久的安全。针对此事，我们不仅把这一批问题全部整改，还举一反三，把代码中类似的场景都进行了整改。后续，经此次的启发，产品还集中专家，针对下层设备和上层设备之间的通信，专门做了系统级的安全加固。看着经过层层加固的代码，大家都舒了一口气，至少现在我们的产品，就算被攻破一个子系统，也不会影响到整个系统。我们开始迈入多防线安全时代。

这让我想起了可信的一个特性：韧性(resilience)。我们的产品正在向这样一种形态转变，它就像水密隔舱技术，哪怕部分系统遭到破坏，整艘大船依旧可以继续航行，至少这是我们努力的方向。

---

“恼人”的可信考试

作为软件工程师，可信考试一段时间以来一直是绕不过的一个话题。每听到科目一、科目二、科目三、科目四的时候，恍如回到考驾照时光，某种意义上，这确实是持证上岗。

在华为内部，对于可信考试的感觉可谓是“爱恨交加”，但是对我自己来说，考完了所有科目再回首，蓦然发现别有洞天：

穿越科目一数据结构和算法的海洋，重新对BFS/DFS（广度优先搜索/深度优先搜索）等算法有了更深刻的理解；

在科目二里翻阅最新的编程规范和安全规范，发现在简短朴实的语言中，已经包含了重要的“Clean Code”（整洁代码）指导，包括命名规则、函数和文件长度、圈复杂度等；

在科目三惊奇地发现，大名鼎鼎的开源居然有那么多商业限制，代码会受感染，在享受便利的时候也要付出；在平时没关注到的编译过程里，居然存在那么多的安全编译选项，可以在更底层上加强可执行程序的安全性；

在科目四中重读设计模式又有新的体会，CSEC的黄金法则言简意赅，确实是有效的安全指引，纷繁复杂的密码算法都是出于历史的不断需求迭代。

不仅是我自己，随着身边同事们一个个通过考试拿到证书，越来越少听到对可信考试的吐槽，相反可以明显感觉到大家的编码能力、可信意识有了质的飞越。毕竟，唯有努力和汗水从不骗人！

---

“戴着脚镣跳舞”

如火如荼的项目开发工作是软件工程师的日常，有一天我突然看到一个让我眼前一亮的OKR（Objectives and Key Results，目标与关键成果，一种绩效管理方法）个人目标：“达成可信交付目标，编码过程遵守可信规范，交付高质量的代码”，这是组内成员小杨在一个样机开发项目中提出的一个目标。我惊讶地发现，大家已经从被动到主动，潜移默化地把可信编码要求带入到日常工作之中，我的内心有点欣喜。

后面组内收集能力提升培训需求时，小杨提出希望能组织培训下最新的编程规范实战经验。“你不是刚通过可信认证全部考试，拿到证书了吗，科目二不是刚考过么？”我笑着问他。“最近规范又有点变动了，马上要做一个新的预研项目了，想找几个资深的研发来分享下他们项目中规范编码最佳实践，我觉得这个挺重要的。”他说道。

对于项目而言，时间永远是“不够”的，每个研发的潜意识里总是焦虑着能否更快的提交代码。然而有一天，小杨找我说，希望给他正在做的预研项目代码仓库加上全套门禁系统，正式在研版本代码提交是必须经过一套复杂门禁系统检查的，而一般预研或者样机项目，更加注重效率和成果。“你这是打算戴着脚镣跳舞啊。”我对他说道。“这样更加安全可靠，代码质量更好，能够直接拦截不合法合入，人都是容易松懈的，有个工具来约束下挺好，顶多我多加点班。”他笑道。

而可信的意识，也给小杨带来了回报——最近他获得了我们部门的“质量之星”荣誉，在其关键质量表现描述上，第一条就是：“在xx项目中累计提交xxK+高质量代码，无遗留问题；xx项目版本，在xx研究院实验室、xx&xx现网等测试过程中，特性稳定，客户满意”。

始于心，终于行，千里之行，始于足下。

行动决定了结果，而思想决定了行动。回首这一路，“可信”之路并不轻松，大家痛苦地前行，但是一路都能收获到努力的果实。我觉得，把可信的思想融入广大软件工程师的灵魂，再用意识之水浇灌产品的可信之花，我们终究会迎来“可信”的明天！

---

感悟

虽然现在大家好像都不太喜欢考试，好像考试都是应试教育那一套，但是就我自己的学习经验而言，只有你把你学的内容当做考试时，才可以学的透彻，了解各种变化，了解各种细节，这不就是基础吗？当然对于编程来说，除了要基础好，还要多写代码，毕竟这也是一个手艺活，熟能生巧。

打好基础加多练，基本上可以解决大部分问题。