总结我的验证思路：我们的代码还需要检视，但检视什么也保证不了

还需要检视，但检视什么也保证不了"/>

总结我的验证思路：我们的代码还需要检视，但检视什么也保证不了

本文转自公众号“数字芯片实验室”，作者：夏晶 。谢谢

再谈检视，首先引用一个对检视的不同观点：review真的最有效吗or导致更多的BUG?

review:中文叫评审。本人见过这个做法的最早出处是朱兰的质量手册。在很长一段时间被软件行业认为是最有效的保证代码质量的手段。在这段时间的质量高压之下,我们再次见到了红红火火的各种代码review,自检,互检,飞检,X检。这让我想起了考试,考试完了都要自己检查几遍再交卷。(当然是在能够把题目做完的情况下),偶尔我们也会在考场上互检(不过这个可能属于作弊)。不过从以上最简单的例子可以看出,互检应该比自检效果好很多,不然也不会有很多学生冒着风险去互检了。

但是上周在和敏捷顾问一起参加一个项目组的回顾会议的时候,发生了这样一个状况,大家在讨论下轮迭代需要改进的时候,都提出来要加强LLT测试用例的review,顾问一直追问我们为什么要这么做？是不是上轮迭代的结果出了什么问题？我们这样做能够带来哪些改善？我们的UT一直做得很弱,顾问非常奇怪为什么我们不多花些时间做UT？而要花时间去做LLT用例的review？当问到从迭代结果上除了什么问题而导致我们想加强LLT用例的检视的时候,大家都找不出直接的证据,只是说:如果不评审,风险会很大。(但是上轮迭代的最大问题大家已经搞清楚了——是低层BSP没有人力投入,导致其中4个相关的Story无法全部完成。

我也很差异顾问提出来这个问题,他继续讲:review有可能是一种浪费。my lady gaga! 我自己从来没有听说过review可能是一种浪费。顾问为什么能够提出这样的疑问？

其实这段时间经常会收到不少项目组发的邮件,宣称自己团队组织封闭检视又发现了几百个问题,似乎是这样做还能得到一些表扬。当时,我内心深处觉得有那么些不对劲,团队1个月的编码工作,怎么能在短短半天的时间里面就可以检视出这么多问题？这也许说明了检视有效,但是是不是更加说明我们前面的工作并没有做好呢？(再次Oh,my lady gaga,我自己怎么都对review产生了怀疑。)

后来忽然在温伯格(«软件程序开发心理学»«顾问工作的秘密»等书的作者)的一本书籍目录中看到了这样一句话,“任何质量措施,益早不益重”。但是非常遗憾,我没有看到全文,只能根据这句话来进行推测和分析(在信息不完整的情况下进行分析是敏捷教练应该具备的能力之一——someone said)。

好吧,我们来看看REVIEW的效果吧。优点:review能够发现问题。缺点:review无法象测试一样可以重复性地保证缺陷没有被引入。

另外，我们可以按照下图方式画出review和BUG的系统控制图:如果我们在如下场景下加强REVIEW,将会进入一个非常有意思的循环,加强REVIEW->发现问题->占用了时间,更没有时间做测试等等->生产更多的问题->review会发现更多的问题->大家认为vreview很有效果->大家会用更多的时间REVIEW->于是产生更多的BUG^^^^^^^^^^

神啊，GAGA啊，感谢这些不同的观点吧，正是有了不同的观点，才让我们能够更加深入讨论的机会。

在我写完前一期的经验总结后，接收到了很多关于检视的不同的观点，很耐人寻味的是，这些反面的观点，基本上全部来自于从Intel、BroadCom等公司背景的高端同事（当然也包括了我引用的这位外籍专家），在这些外来的，充满魅力、经验丰富的男人们看来，强调检视是属于海思（从引用的专家的指向，整个华为也是如此）的专利，而被人直接用肉眼发现代码中的缺陷，简直就是人生中的奇耻大辱，真正保证设计正确的，只能是有激励的仿真。

其实我非常赞成楼上最好的一个描述，真的，非常赞成。检视，只是检视，只是能偶尔地，发现一些错误而已，检视什么也保证不了，检视既不能保证Bug被全部发现，也不能保证这些偶尔发现的Bug能被修正或不被重犯，更重要的是，检视根本无法保证设计最终能够正确运行，最终能够保证设计正确运行的，只有仿真。

但是，为什么我们常常从检视活动中受益呢？难道真的如我引用的文字所述，我们也陷入了强调检视，而弱化测试，然后检视出更多Bug，而更加强化检视、弱化测试的循环？

下来后，我进行了反复思考和交流，得出了我的一些观点，以供参考。OK，我并不是想驳倒前面的观点或证明什么，不同观点之间的激荡间，我相信读者自有能力分辨和获取自己的观点。

首先，那些经验丰富的男人们，也是会进行代码串讲的，他们不把这个算成检视（我们算检视），而算设计流程的一部分。OK，这一点点误解只是一个欲盖弥彰的借口，呵呵，连我自己都害臊了。

我真正的观点之一，是我们的设计人员，还不够成熟。在国外，十年甚至二十年经验的编程人员比比皆是，所以，这些经验丰富的男人们，周围也是经验丰富的男人，而在国内，十年或者二十年经验从业的，只要还没累死，基本上不是领导就是架构师了，写代码？还是给新员工锻炼的机会吧！所以，我们的代码，往往都是经验小于3年的人员编写的。我妄自揣测，在海思内部，编写逻辑代码（非C、JAVA）超过10万行的，屈指可数，超过20万行的，很可能已经绝迹。在这种2～3年经验设计人员编写的代码中，认真检视一下，发现问题，其实并不是件很难的事。嗯，我并不是在嘲弄我们的设计人员，因为，一个人的成长，一定是需要经历磨练的，正如《成长的烦恼》所演绎的，没有人能够一天就长大。我自信我不是很愚钝的人，但我也是整整写了3年的代码之后，才真正醒悟：一份代码，在写完之后，一定要再经过一次或多次整理和打磨，才能算完成的；一份代码，一定要把其有效代码行，精简、锤炼到最少、最短、最有效，才能算完成的。前一个月，海思有一位叫聂世玮的兄台讲过一次Verilog编码，也是这么个道理，只是不知道有多少听者真正明白了，不过不明白也没关系，再经历几年磨砺，如果还在写代码，就明白了。所以，我们的代码，还需要检视。

我真正的观点之二，检视，并不能替代仿真，甚至不能让整个仿真的动作有任何减少，但检视确实能够缩短整个仿真的收敛时间。因为，我们设计人员不成熟的同时，验证人员同样不成熟。我看过太多的验证人员，随机向量跑出来一个Bug，然后和设计人员抱着显示器追波形，太阳升起，然后落下，再升起，再落下。如果定位并解决一个Bug平均需要半天（真不算慢，虽然那些经验丰富的男人们认为这只是分分钟的事），那么一个设计如果有40个Bugs（不是夸张，比这数字高的多得要命），光定位就花掉了20天，还不算期间项目组例会、设计组例会、验证组例会、攻关组例会等等的时间。真是累啊，不是兄弟们不努力啊，而是敌人太凶残啊。所以，我们要检视，只要通过一整天的时间检视，能够发现其中1/4的Bug，就赚大发了啊。当然，检视发现的问题，一定是需要仿真再覆盖确认的，仿真的工作，提取Feature，写TC，一个都少不了，但定位和回归，可以大幅缩短。

我真正的观点之三，检视，能够偶然发现某些仿真遗漏的重大问题，对，是偶然。但是，我也曾经说过，一次是偶然，两次是偶然，三次就是必然。验证空间是无限大的，而如何使用有效的仿真覆盖无限的空间，我们依旧经验不足。所以，这里还是有检视的空间。

基于观点一、二、三，所以我认为，检视，能够很大几率缩短项目收敛时间，并发现一些隐蔽的问题，颇具投资价值。

检视很重要，但千万不要迷恋检视。检视的成功，是典型的不可复制型。所以，检视，可以成为流程中的一个步骤，但绝不是流程中用以保证结果正确的方法，换句话说，我们可以定义一个设计需要检视多少次，但绝对不应当定义这个设计的Bug，有多少比例应当在检视中发现。因为，影响检视效果的因素太多了，天时、地利、人和，缺一不可。某位检视人员前天和老婆吵架了，或者会议室空调太冷，都可能使得检视效果发生天翻地覆的变化，所以，不可依靠检视。如果检视效果不佳，一切还是只有靠仿真。

这里，再共享一个我检视的经验。我把检视分为私下单P的检视和会议室中的群P的检视，单P的检视，一定要结合波形进行，后面专门讲，这里讲群P，群P的大部分时间，我都是精神不振的，因为一群大男人聚在一个小屋子里，实在没啥好鸡动的。等待，耐心等待，一旦讲解代码的设计人员语速放慢了，或者出现迟疑了，发出了例如“嗯”、“这个”之类的拖延时间的助词，马上提问，要求讲清楚，不清晰的地方反复提问，要追根究底，飞流直下三千尺，语不惊人死不休。能确认的，现场就可提单，有疑问的，下来对照波形Check。

最后，Remember，我们的目标只有一个，发现Bug，检视只是实现这个目标的一个手段而已。刀在手，是屠夫还是侠客，存乎一心。