因修改報表名稱引起的「慘案」

臨近年末，憋出了個嚴重BUG。 特此記錄，覺得警示。

背景

爲了規範導出報表，將報表名稱由原來的 corp_parammd5hash.csv 改爲了 corp_2017-01-10-11-12-13.csv 形式，致使了商家A下載了商家B的報表，引起嚴重的安全問題。

緣由

這是由於 corp_2017-01-10-11-12-13.csv 文件名沒有區分度， 保存到服務器上時， 是 /path1/path2/報表文件名， 其中 /path1/path2 是根據系統當前時間戳解析獲得。若是兩個商家同時在 2017-01-10 11:12:13 導出，對應時間戳是 1484017933 , 那麼，兩個報表都會保存到文件 /148/401/youzan_2017-01-10-11-12-13.csv ；這樣，當不一樣商家在同一時刻點導出時，就會致使報表文件覆蓋，最終致使一個商家下載了另外一個商家的報表，而本身的那份已經不存在了。 一個辦法是增長 corp_id ， 但也解決不了同店鋪報表覆蓋的問題。 這是因爲這個報表名稱處於公共函數範圍， 也影響了其餘導出類型的報表文件。

這件事作得也比較急促， 出於對本身代碼質量的信心，徵求產品同窗承認後，新舊導出報表名稱改動的開發、測試、驗證、發佈整個過程在3-4小時內完成，沒有仔細推敲原有設計，沒有意識到這個改動會產生文件名衝突覆蓋的問題， 也沒有跟產品同窗作一次同步確認，最終致使了嚴重BUG。

從另外一個角度來看，也是前任留下的文檔匱乏，對於特別要注意的地方沒有任何提醒，接手的人不知道，很容易就踩坑了。 所以，當開發和維護一個系統時，必定要記得把一些關鍵的坑點記錄下來，提醒本身，也爲別人留個好路。

教訓

• 勿以事小而不慎。
• 認真記錄「坑點」。
• 對外的名稱修改時，切記要保持不一樣用戶的區分度，避免安全問題。
• 評估改動時，第一個考慮應該是影響範圍，而不是代碼改得對不對。
• 原有代碼改動時，必定要兼顧總體設計和原有設計。
• 多積累設計知識，有設計敏感度。

忽然想到，任何形式的Bug或加班或非適當的勞累，都是由於咱們的思惟或技術或制度的侷限性與現實需求的差距致使的。

好像是廢話。