浅谈我从修复bug的过程中学到了什么

引述

前天和系统工程师讨论一个新的需求，需求描述很简单就是定时向TSP发送车辆的位置信息。

由于需求描述很简单，我也没有过多的考虑多种场景，三下五除二就完成了设计并coding完成，之后简单测试一下就提交了代码。

bug的描述

内测版软件发布后，MCU团队测试该功能时发现了问题。由于我设计的是两分钟的定时器，即接收到MCU的消息后，等待两分钟再上传数据到TSP。

但MCU团队测试时发现上传数据的时间不固定，有时30秒/有时1分钟。

这个现象很奇怪，因为我设计的定时器是固定两分钟，怎么会出现时间不确定的情况呢？

bug的分析与修复

与MCU团队仔细沟通了测试步骤，并且查看了测试log发现了问题所在。

MCU团队利用CANoe定时给我发送消息，但时间小于2min。这就导致多个MCU消息共同分享一个定时器的2min，因此发送消息越多，等待的时间就越短。

其实，软件完全符合需求，但设计不够合理，未考虑到MCU团队测试时并不会等待上一次定时器结束后，再发送消息给我。

但考虑到该功能前期时开发利用了多线程技术，即允许MCU能够随时发送消息给我。

为了设计的一致性和软件的鲁棒性，我重新设计了该功能的定时器，设计代码结构如下：

#define TIMER_MAX_NUMBER   20  /* 因为线程数量就被限制在20个 */
typedef func_timer_
{
    int timerID;  /* 定时器的ID */
    int totalTime;
    void *userData; /* 用户数据 */
    bool isValid; /* 判断定时器是否可用 */
}func_timer;

func_timer mcu_timer[TIMER_MAX_NUMBER] = 0;

/* 每次起新线程时，都重新创建一个定时器 */
for(int index = 0; index < TIMER_MAX_NUMBER, index++)
{
    if(true == mcu_timer.isValid)
    {
        mcu_timer.isValid = false; /* 表示该定时器已经被占用 */
        mcu_timer.timerID = createTimer(delay_function, mcu_timer.userdata);
        mcu_timer.totalTimer = 120;
    }
}

bug修复之后的测试

代码修改完成后，拿去给MCU团队测试，功能完全正常并未出现之前的情况。

此外，不论他们怎样修改每次消息发送的时间间隔，软件均能正常处理来自MCU的消息。

总结

这个bug很容易发现，修改起来也相对容易。但从解决bug中，我真切感受到软件前期设计的重要性。

测试场景可能并不完全符合真实场景，测试更加严格，所以设计代码时要考虑到代码的可扩展性和健壮性。

程序员在设计某个功能时，不要只盯着某条需求，简单设计，简单coding，到后期不停的修改bug。

合理的做法应该是站在整个软件的层面来针对需求进行设计，尽量在一开始就尽可能多的考虑从多种场景，在设计时尽量规避可能出现的问题，这样才能最大程度保证软件的鲁棒性。

Note

接下来的文章会将我近两年在汽车行业软件开发所学到的知识总结一下，主要有以下几点：

• Function Safety：我经历的第一个项目就参与到某ECU的软件功能安全团队做开发，功能安全在未来汽车行业会越来越重要，是非常好的发展方向。

• ASPICE：我现在参与的项目正在经历ASPICE LEVEL 1的评审，在评审过程中也学习到一些新知识，打算总结分享一下。

• AutoSAR：公司培训过关于AutoSAR的基本知识，但没有实际操作过，准备向部门大牛请教，学习一些AutoSAR方面的知识。

• Ethernet：目前参与的项目是通过以太网与车辆的其他ECU进行通信，对于以太网的知识也算是了解一些。车辆以太网通信是未来汽车内部通信的主要方式，打算将自己所学到知识总结一下。

• V开发模型：我之前写过一篇“V”开发模型的文章，但随着工作经验的增长，对于V模型有了一些新的理解，打算重新介绍一下V模型开发

欢迎关注我的公众号：** 酷酷的coder**