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

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

 

再谈检视,首先引用一个对检视的不同观点: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,检视只是实现这个目标的一个手段而已。刀在手,是屠夫还是侠客,存乎一心。

 

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页