0
收藏
微博
微信
复制链接

嵌入式系统开发,如何一次就把事情做对?

2024-08-26 15:47
156

不知道你有没有注意到,走进各个企业,总能看到那么几句振奋人心的标语,其中“一次把事情做对”绝对是个高频词汇。


以前每次看到,我都会想:这家企业也太教条了,都什么时代了。对失败这么零容忍,还怎么创新呢。这个时代的主旋律不是从错误中学习,快速响应、快速迭代吗。

然而最近一年的嵌入式领域经历,让我重新反思,“一次把事情做对”不仅是对工作效率的追求,更是对质量控制的严格要求。在嵌入式产品开发领域,这一理念的重要性尤为突出。

与Web系统相比,嵌入式产品有其独特性。它是软硬件的紧密结合体,不易升级,一旦发布,出问题的解决成本异常高昂,后果更为严重。所以“一次把事情做对”就是一个合理且必要的目标了。

但是怎么做到一次把事情做对呢?我们从 4 个原则来聊聊。

不做就不错


在生活中,我们常说“不做就不错”。在工作中,我也要把这个原则送给你,它仍然是真理。说白了就是:没代码,无bug。

我不是说让大家不干活,而是在没搞清楚需求之前,千万别急着动手。你想想,画画草图、写写文档总比直接写代码来得轻松吧?而且成本也低多了。如果错了大不了重画重写,可是写成了代码,那就叫 bug。

你要学会拒绝需求。需求来了,你得想想这需求有价值吗?合理吗?如果对方说不清楚价值,给不出理由,那你就应该拒绝。告诉他不要浪费你的时间和公司的金钱。

你得要求明确的需求。当业务方提出技术规划或者需求时,BA(需求分析师)就要分析清楚这个需求的细节,一句话的需求太模糊,没法干,开发者也要拒绝。这是你的权利。一旦你干了,出了 bug 那就是你的错。


但你可能要问了,有些需求在初期就是模糊的,只能在做的过程中慢慢摸索,那怎么办呢?

记住,不做就不错,不写代码就没 bug!你问问自己,需求是模糊的,可你的代码能模糊吗?你写个模糊的代码让大家看看。计算机只能分清0和1,根本就不会模糊处理。


所以即使需求是模糊的,但你写不出模糊的代码。如果你写出了代码,必然是你把模糊的东西变成了确定的东西,那你大概率就写了个bug。


正确的做法是,需求必须明确,不能模糊。如果在产品初期,摸索阶段,那么BA应该提出假设,进行验证。提出假设后,需求就是明确的。我们假设是这种情况,代码就这么开发,先验证,不断迭代就能逐渐找到更好的答案。


这种通过假设来明确需求的方法叫试错,你拿着模糊需求写成不模糊的代码,那叫 bug,这两者的区别你自己体会一下。

f11cc975ea20cb39c779e2972da588.jpg

少做就少错


现在我们把能拒绝的工作拒绝了,把模糊的需求明确了,剩下的就是不得不做的了。我要送你的第二个原则是,少做就少错。


怎么做到呢?千万别急着动手写代码,否则你很可能来回反复要走不少弯路才能做对。我给你个三步法,让你少走弯路、少写代码,少出错。


第一步,脑中做一遍。你先在脑海中预演整个实现过程,这类似于一种虚拟的模拟运行。你要想清楚每一步的输入输出是什么,处理过程是什么。这一步很重要,它能确保你真正理解了需求,并提前发现潜在的问题和难点。


第二步,纸上画一遍。把你脑中预演的过程在纸上画个草图。这个过程不仅有助于整理思路,还能帮助你和别人沟通讨论。记住,一定要画出来。有时候你以为你想清楚了,画出来你才发现没想清楚。


第三步,找人问一遍。经过前两步,你对需求理解透了,实现方案也想清楚了。这时候你要找人问一遍。这个人最好是个有经验的人。他能对你的方案提出建议,也能发现你没注意到的、可能对原来的功能有影响的地方。即使对方没有经验,你也要找人问一遍。因为在你讲的过程中,你自己就能发现一些问题。


经过这样三步的准备和验证之后,你就可以信心满满地开始编写代码了。这时你在面对复杂问题时会从容不迫,出错的概率也大大降低。


让机器多干活

前面铺垫那么多,你可能都觉得那不是好好工作,只有写代码才是真正工作。其实你写的代码是非常宝贵的东西。产品的价值都是靠你一行行代码实现的。前面的铺垫就是为了让你能真正写好代码。

现在你终于开心地写着代码了。你要思考的是自己怎么少干活,怎么让机器多干活。毕竟,不做就不错,少做就少错。

这里我们暂且不提让AI来帮你写代码。你想想你在开发过程中,哪些工作是可以交给机器来做的呢?

开发的工作可以分为三大块:看代码、写代码、调试验证。验证对你来说既无聊又耗时间。你打着断点,看着变量是不是你想要的值,逻辑跳转对不对。这样的工作不停地重复着,有时候一抬头发现周围人都走光了,一天很快就过去而你还没定位到问题。

验证这部分是最容易交给机器来做的。你完全可以写个验证代码(测试代码)来验证程序的输出对不对,是不是你想要的结果。这是个一劳永逸的方法。验证代码你只要写一遍,它就在那里,孜孜不倦一遍遍运行着。你完全可以放心交给它帮你完成验证的工作。再进一步,你甚至可以先写验证代码,再写业务代码,这就是极限编程中的测试驱动开发(TDD)。

机器还可以帮你干其它活,那些重复的活你都可以让它干。所以这第三个原则“让机器多干活”还有另一个名字:自动化一切能够自动化的工作。

比如你的软件的构建,部署,一切能够自动化的工作,都应该交给机器来做。因为人都是会犯错误的。

aabf712e12eeb8b7db68ef6cc5b6d6.jpg

早纠错、少浪费

前面三个原则讲的都是尽量地少干活,但只要干了活,就可能出错。所以最后这个原则是“早纠错、少浪费”,怎么尽早地发现错误,减少浪费。

对于产品研发来说,最大的浪费是返工。因为功能做得不对返工,因为质量问题返工,这些都造成品牌受损,成本增加。

问题发现得越晚,成本越高。所以我们要通过一切手段尽早纠错。极限编程提供了一个很好的参考机制:

  • 分钟、小时级别的反馈:通过结对编程、自动化测试、流水线完成。

  • 天级别的反馈:每日站会、每个需求的验收测试

  • 周级别的反馈:每个迭代的showcase

  • 月级别的反馈:版本发布后的反馈


如果我们能建立极限编程这样的从分钟到月级别的多维度反馈机制,我们就能够在早期阶段及时察觉问题、纠正错误,从而显著提高工作质量并减少不必要的浪费。

总结

产品质量就是企业的生命线!嵌入式产品由于其自身特点,追求“一次把事情做对”是每个研发人员的追求。通过文中介绍的四个原则和相应的实践,建立多维度的反馈机制,你就能够最大化实现质量的提升和资源的充分利用。

登录后查看更多
0
评论 0
收藏
侵权举报
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表凡亿课堂立场。文章及其配图仅供工程师学习之用,如有内容图片侵权或者其他问题,请联系本站作侵删。

热门评论0

相关文章

工程师进阶笔记

我是老温,嵌入式物联网工程师,热爱学习,热爱生活,愿世界和平!

开班信息