近幾個月來的工作是一個交易系統持續改進項目，迭代發布周期大約為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>