程序員,時間都上哪兒了


       晚上調試修復了一個線上的小 BUG, 花了2個小時, 加上昨天花費的時間, 總共大概3個小時。

       BUG 是這樣的: 一個 API 返回的 JSON 串是一個對象數組 [{field1: 'xxx', field2: 'xxx',  'source_cidr_ip': 'xxx'}, {'field1': 'xxx', 'field2': 'xxx', 'source_group_no': 'xxx'}] , 有一個字段是可能變化的, 大多數時候是 source_cidr_ip, 極少數時候是 source_group_no , 所採用的 JSON 解析庫是 JACKSON-lib , 這個庫對要填充的對象定義有一些要求: 所聲明的對象的屬性必須包括所有 JSON 串中的字段, 若少了則會報錯, 若多了則會填充爲 null. 而我定義的對象中只包含了 field1, field2, source_cidr_ip 三個字段, 忽略了 source_group_no , 結果當返回含有 source_group_no 字段的 JSON 串時, 就會出現解析異常。 


      爲什麼花了這麼長時間呢? 按理來說, 這樣的 BUG 只要查看一下日誌, 是很容易定位的; 原因可能有如下三個方面: 1.  返回含有 source_group_no 的 JSON 串出現的概率非常低, 也許只是最近纔出現, 否則應該早就報出異常了;  2.  出現 BUG 的時間距離開發的時候已經過去了近 7-8 個月了,  料想到是這些細節壞事還真是不容易; 3.  這個解析異常可能被多線程中的代碼“吃”掉了(切忌把異常捕獲了卻什麼都不處理!), 以至於沒有看到。   


      令我痛心的是, 這樣一個小 BUG 就耗費了我大概3個小時! 如果把調試時間加到開發時間上, 那麼這個小小的展示功能實際上是耗費了4-5個多小時! 由此, 我想到了, 程序員, 你的時間都上哪兒了 ? 


       我們程序員常常自豪地宣稱: BUG, BUG! 無休無止, 無窮無盡的 BUG! BUG 是無法避免的, 然而, 如果在開發時能夠更加仔細一些, 更加苛刻一些, 是不是可以減少無謂的調試時間? 減少這些不必要的調試, 是不是可以節省出更多時間,用於更有意義的事情上? 捫心自問, 你是不是花了 1個小時開發, 又花了2個小時(常常是一點一點地累積出來的)不斷地調試和修復?  這是不是咎由自取, 自食其果? 雖然當時可以自豪地對主管說, 我達到了預定的工期和目標, 實際上很可能是自欺欺人。你的主管不會在意你在工期之外所花費的時間, 但你必須在乎。 因此, 快速開發, 有時是得不償失的。 看到了眼前的“快”, 卻看不到爲前面埋下了“雷”。


        因此, 在開發時儘量苛刻一些, 充分測試, 對代碼質量充分重視, 實際上是儘量減少無謂的調試時間(離開發時間越久遠的BUG, 修復所花費的時間會越長), 從總量上節省了時間。


        從另一個角度來說,  程序員應當對自己的時間非常敏感, 畢竟, 技藝永恆, 生命短暫; 多留點時間給所愛的人!



發佈了197 篇原創文章 · 獲贊 55 · 訪問量 44萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章