团队是我未测试的代码的威胁?个人。
那么糟糕的信任燃烧调试周期来自地狱的声音,这是比你想象的更糟。我们大多数人没有意识到它的存在。在我的前十年的硬件开发人员写代码像它永远存在!但随后实现。这是一个循环它是以我们所有人。它诱使我不断。
我们大多数人在硬件开发用于看到虫子烦恼至少,但更关键的是块和很大。他们生长在数据库和成为清单,站在一个团队的一部分,其交付的目标。最终达到进度超出他们的伤害。表面上这是有道理的,因为计划是钱的地方。但损失超出计划的成本超支。
真正理解信任燃烧调试周期从地狱我不得不停止思考错误的简单计划超支和开始考虑损伤使用公制,总是让我紧张:信任。测量受损的信任意味着我开始问自己这样的问题“做我的同事、经理和客户信任我做我的工作好吗?”没有人希望这个问题的答案是“不”,包括我。
不幸的是,信任是容易燃烧。当验证工程师为其他团队构建贵宾,我们倾向于code-n-release方法:VIP编写代码后很快发布给用户。我们通常会放弃,或者至少延迟严格的测试,认为这将原位更有效的解决问题。用户通常很多bug。每一个错误成本调试时间。令人沮丧的调试的每一分钟都会是一种负担,使他们有机会问题我们交付的能力。
取决于你正在使用一些bug可能最终被接受。当它变成了不少;当错误出现的周期;当它是一个常数debug-fix-and-release,开始和用户开始失去信任的问题。
好消息是,VIP的早期测试可以帮助我们与用户建立并保持信任。基本上,你的错误在您的代码在其他人之前避免传递他们前进。两种方法我使用测试驱动开发(TDD)和单元测试。这两种技术都借鉴了软件开发,非常适用于硬件开发和帮助我避免来自地狱的信任燃烧调试周期。
或者我应该说几乎避免它…
…因为坏消息是,即使有了正确的方法,仍然可以oh-so-tempting匆忙对过去的连续测试和交付给用户。我讨厌承认这一点,但对于所有的练习,写作和时间我致力于TDD,有时我推迟在压力下质量。我梦想自己的情况相信未测试的代码很好的避免来自地狱的信任燃烧调试周期。但相信我的代码从未足以把我的梦想变成现实。总是,我未测试的代码对团队成为一个威胁。我保存在开发很容易被沮丧的用户。最糟糕的是,合适的代码做交付使用TDD是bug的代码我生产没有黯然失色。
和人民对我的信任吗?一去不复返了。至少这是感觉的方式。我讨厌每次我试着节省时间别人的代价。遗憾的是,它仍然是我忍不住尝试似乎我需要它的时候,即使我知道结果如何。
这个故事的寓意是:看到我用测试驱动开发和单元测试的改进构建贵宾时帮助我意识到自己所率领的伤害我。这的普通的一天。bug数据库中的条目或周多加入一个时间表;他们现在是我的个人。我建造;他们是我的错。
这听起来像一个充满压力的工作方式但只有紧张当我诱惑与旧code-and-release偷工减料。因为我每次陷入旧的习惯,在那个角落等我信任燃烧调试周期从地狱…笑迂回…高兴我回来的。
有关的故事
调试:自动化的最后堡垒
民间传说错误地声称验证消耗了70%的开发时间。但调试真的消费50% ?
调试成为一个更大的问题
EDA公司发展更多的集成调试流将执行引擎和硬件和软件紧密联系在一起,但这是否就足够了呢?
得到正式的关于调试
正式的技术是在调试过程中,发挥着越来越大的作用和一些基本的新方向探索使调试更加自动化。
|
|
|
|
|
|
|
|
|
|
FPGA团队5月我加入使用TDD和单元测试已经几年了,内部称为团队不释放错误。这不是完全真实的,但相比之下,所有的西南团队在公司里,也使用TDD和单元测试,他们做得很好,他们做得更好比以往采用这些实践。这些的工作方式是伟大的如果你不管到HW或SW编码。
There should be an AA style meeting for this kind of thing I’ve always held it as a point of pride that I document what I want my code to do before implementing it. I occasionally backslide, and my code suffers for it every time.Same thing with testing. I know I’ll wind up saving hours or even days if I just build the damned test harness, but the temptation is huge just to ‘crank out the code in a few minutes, and get on with life.’
汉密尔顿,AA-style会议上你是对的!伟大的比喻!我知道这是错的,但我有时会说服自己,跳过测试是好的。也许你缺少的是集团的支持