工作思考：关于软件 Bug（1）
身为一个在 Tier1 工作多年的软件工程师，伴随着汽车电动化与智能化的转变，我深刻地感受到了当前软件开发模式正发生着翻天覆地的变化。
曾经的 V 模型是很好，但当前的人力和节点压力已经很难满足项目的需求。敏捷开发其实也不错，但一旦出了点小 Bug，就总会有人问你：这做了没有？那做了没有？
一些天天喊着“质量”的人，没有被客户火烧屁股的人，是无法理解这种转变的发生。一遇到问题就是一套指导书式的发问：你这个测了没有？你怎么没有按照流程来开发？有没有相关的开发指导书？
每当听到这句话的时候，我就只能在心里叹气：他们对于软件质量的组成可能一无所知。难道从未有人知道：
当软件复杂到一定的程度，就不是一个简单的指导书能够 Cover 的了。而复杂的指导
书，就别指望员工每次都会老老实实地落实执行。
而归根结底，他们始终没有意识到，在如今这样的开发节点的需求下——在开发过程中，甚至量产中，软件没有 Bug 是不可能的！而具体的原因也显而易见：
控制器硬件的频繁迭代更新 🔁
开发人员的不断流动，能力的流失，开发者水平的参差不齐
某些 OEM 不成熟，甚至是不合理的需求
近乎疯狂的开发节点需求……
很遗憾，依旧有很多人拿着旧时期的思维来要求新时代的汽车软件，却将汽车软件开发中的“不可能三角”抛在脑后……
因此，我们必须要意识到当下的软件开始模式已经发生了转变。我们也需要更坦率地承认：软件开发过程中出现 Bug 是很正常的这一事实。
当你意识到 Bug 不可避免的时候，我们就会将更多精力放在那些：常见、严重的 Bug上面。而不是妄图通过流程与指导书，来避免所有 Bug 的发生。 （当你有1000 本指导书的时候，你是否需要写一本寻找指导书的指导书？）
根据“80%法则” —— 20% 的 Bug 将会造成 80% 的伤害。因此，只要我们对关键步骤进行重点关注，就能最大程度地减轻软件 Bug 所造成的影响。那么对于 Tier1 而言，什么算是严重的 Bug 呢？我们下次再聊～
汽车ECU设计
一个菜鸟程序猿的成长之路。116篇原创内容
公众号
✍🏻 知 乎：@META👬 公众号：@汽车ECU设计
历史精华文章集合：
工作思考 · 目录
上一篇 下一篇
2022年终总结 工作思考：关于软件 Bug（2）