將算法實現(xiàn)后，有可能并不會像我們以為的那樣生效。比如代碼中出現(xiàn)bug必逆、計算公式寫錯幅垮、源數(shù)據(jù)異常、資源緊張導致程序運行失敗隙疚，這些情況都會導致實際的結(jié)果與我們以為的不一樣壤追。
隨著開發(fā)經(jīng)驗的增加，這些情況會越來越少供屉。但經(jīng)驗不具有復制性行冰，不能把別人的經(jīng)驗直接copy過來。這不是說別人的經(jīng)驗對你沒用伶丐，而是說很多事情只有自己經(jīng)歷過悼做，才知道是怎么回事。而且經(jīng)驗也不具有穩(wěn)定性哗魂，總可能會出現(xiàn)意外遺漏某些東西肛走。
解決這個問題最好的辦法是列出可執(zhí)行清單，原則上一份完整的清單上就能避免“事故”的出現(xiàn)录别。最能說明這點的地方就是機場朽色，每架飛機起飛時邻吞，即使機組人員對流程很熟了，還是會對著清單一項項的檢查葫男。
最近五個月抱冷，我經(jīng)歷過幾次“事故”，有自己造成的梢褐，也有別人引起的旺遮。為了減少再次掉進坑里的可能，我總結(jié)出了一些清單盈咳，這些清單就是算法真正實現(xiàn)的后勤保障耿眉。
我的清單如下：
- 源數(shù)據(jù)是否有過濾臟數(shù)據(jù)
- 每個功能函數(shù)是否都有測試用例
- 關(guān)鍵的中間數(shù)據(jù)是否有保存
- 是否在源數(shù)據(jù)以及最終輸出算法結(jié)果增加了監(jiān)控報警
任何算法實現(xiàn)的前提條件是有數(shù)據(jù)。數(shù)據(jù)中常出現(xiàn)兩個問題猪贪，一是臟數(shù)據(jù)跷敬。比如商品id本應是數(shù)字，但部分商品id出現(xiàn)了其它字符热押。
二是數(shù)據(jù)信息量不對西傀，即算法接收到的數(shù)據(jù)和實際的有偏差。數(shù)據(jù)傳輸環(huán)節(jié)越多桶癣，這種情況越有可能出現(xiàn)拥褂。
臟數(shù)據(jù)可能會導致程序報錯然后退出，使算法無法更新牙寞。所以這里要有三層保障饺鹃，一是過濾臟數(shù)據(jù)，這能保證算法正常更新间雀。臟數(shù)據(jù)總可能會出現(xiàn)悔详，所以第二層保障是增加監(jiān)控報警，當算法輸出的結(jié)果文件沒有更新時發(fā)送報警信息惹挟。
過濾了臟數(shù)據(jù)雖然能保證算法正常更新茄螃，但要是臟數(shù)據(jù)過多怎么辦呢？比如由于技術(shù)故障導致大面積的商品id出現(xiàn)問題连锯，在這種情況下算法更新也許還會導致更嚴重的后果归苍。
數(shù)據(jù)信息量不對這件事就難辦了，特別是正處在發(fā)展期的公司运怖。往往是出現(xiàn)了問題之后才有可能去檢查數(shù)據(jù)在傳輸過程或自己代碼中的過濾條件導致信息量不對拼弃。為了讓檢查能快速，所以可能提前保存關(guān)鍵的中間數(shù)據(jù)摇展。比如開法個性化推薦算法時吻氧，商品或用戶的匯總數(shù)據(jù)。
解決完數(shù)據(jù)的問題之后就是要保證代碼邏輯正確了。我曾經(jīng)在開發(fā)一個推薦算法時医男，把排序值的計算公式給改錯了砸狞，等線上出問題了用git查看記錄才發(fā)現(xiàn)這個問題捻勉。
而解決邏輯問題最有效的辦法就是寫測試用例镀梭，正常情況下每一個函數(shù)應該至少準備一個測試用例。這樣做的前提是你開發(fā)的算法代碼不是只有一個主函數(shù)踱启，主函數(shù)中的每個功能盡可能的寫成函數(shù)的形式报账，這樣通過主函數(shù)就能了解整個算法的邏輯，而測試用例能確保每個功能函數(shù)是按正確的想法實現(xiàn)的埠偿。
由于數(shù)據(jù)是大家共用的透罢，所以很多數(shù)據(jù)的問題，即使自己沒發(fā)現(xiàn)冠蒋，別的同事也能發(fā)現(xiàn)并修正羽圃。但代碼邏輯是否正確卻只能靠開發(fā)者自己。所以是需要開發(fā)者花大精力去保障邏輯的正確性的抖剿。像上面說的那種錯誤朽寞，其實只需要一個測試用例就能找出問題所在。
清單也是需要不斷完善的斩郎，每次發(fā)現(xiàn)新的問題時想辦法解決脑融，并把它加入清單。只有這樣缩宜，清單才能不斷完善肘迎，發(fā)揮其作用。
