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