引述
前天和系統工程師討論一個新的需求，需求描述很簡單就是定時向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**