近幾個月來的工作是一個交易系統持續改進項目,迭代發布周期大約為2~3周。最近一次迭代是V16版,在禮拜三完成發布。不幸的是,第二天上午就被老大逮過去。原來老大從生產中揪出了一個bug,大致的問題如下:
系統中有一個常用的自定義控件,目的是協助選擇客戶,而V16版的持續改進需求是給控件增加兩個篩選選項,支持不同的默認值配置。很簡單的一個需 求,代碼修改也簡單,其中一個修改是給一個js文件裡邊的一個函數增加了一個傳入參數,用來傳遞配置值。經過RC、RTW測試,一切都顯得很正常,不過上 了生產才被發現bug了。加載出來的客戶明顯不正常、數目不對,也與預期的查詢配置不相符。
檢查控件內部跳轉鏈接,發現問題,傳遞的參數明顯與預期不符,而這個鏈接則是由上面修改過的JS函數生成。因此判定問題是由於客戶端緩存了原版JS 文件,新函數的調用由舊函數所替換引發的。經過清除緩存,重新加載頁面後,這個自定義控件能夠正常工作。很不幸的是,我們是不能通過打電話告訴每一位用 戶,你需要清除緩存,然後才能正常使用這個功能。
到此時,我才意識到需要一種方法來控件JS的緩存問題,否則,後續任何涉及JS文件內容的修改,都會因為緩存無法獲取最新JS文件,而導致生產事故。
原則上,我們是需要在有JS更新的時候,才會去重新加載JS文件,而不是每次都重新加載,因此第一種做法給JS應用地址後添加隨機參數是不可取的,因為它意味著,幾乎每次加載頁面都會是重新加載JS,而不會合理的利用緩存JS。但是,我們還有第二種更合理的做法,如果關注過一些國外網站代碼,會發現,他們通常是在js鏈接後添加一個版本號參數,而不是隨機數,當js代碼發生修改時,只需要將版本號加1,就可以很巧妙的解決通知客戶端更新js文件。不知道,誰是第一個想到這種方法的人,不過毫無疑問,他是值得我們欽佩的,真是一個不錯的idea的!
附贈些許代碼:
<script src="../JavaScript/SelectOpenWindow.js?v=1" type="text/javascript"></script>