相信大家在開發軟件和進行軟件維護的時候也會發現，有時候我們會針對壹些軟件的功能進行代碼重構來讓系統運行更加的穩定。今天回龍觀java培訓就壹起來了解壹下，在代碼重構的過程中都會遇到哪些問題。
1、離線任務和模型的管理問題。我們做在線服務的都有體會，我們經常容易對線上業務邏輯代碼更關註壹些，而往往忽視離線代碼任務的管理和維護。但離線代碼任務和模型在推薦場景中又至關重要。因此如何有效維護離線代碼和任務，是我們面臨的壹個問題。
2、特征日誌問題。在推薦系統中，我們常常會遇到特征拼接和特征的『時間穿越』的問題。所謂特征時間穿越，指的是模型訓練時用到了預測時無法獲取的『未來信息』，這主要是訓練label和特征拼接時時間上不夠嚴謹導致。如何構建便捷通用的特征日誌，減少特征拼接錯誤和特征穿越，是我們面臨的二個問題。
3、服務監控問題。壹個通用的推薦系統應該在基礎監控上做到盡可能通用可復用，減少具體業務對於監控的開發量，並方便業務定位問題。
4、離線任務和模型的管理問題。
在包括推薦系統的算法方向中，需要構建大量離線任務支持各種數據計算業務，和模型的定時訓練工作。但實際工作中，我們往往忽略離線任務代碼管理的重要性，當時間壹長，各種數據和特征的質量往往無法保證。為了盡可能解決這樣的問題，我們從三方面來做，壹，將通用推薦系統依賴的離線任務的代碼統壹到壹處管理;二，結合公司離線任務管理平臺，將所有任務以通用包的形式進行管理，這樣保證所有任務的都是依賴新包;三，建設任務結果的監控體系，將離線任務的產出完整監控起來。
5、特征日誌問題。
AndrewNg之前說過：『挖掘特征是困難、費時且需要專業知識的事，應用機器學習其實基本上是在做特征工程。』我們理想中的推薦系統模型應該是有幹凈的RawData，方便處理成可學習的Dataset，通過某種算法學習model，來達到預測效果不斷優化的目的。
但現實中，我們需要處理各種各樣的數據源，有數據庫的，有日誌的，有離線的，有在線的。這麽多來源的RawData，不可避免的會遇到各種各樣的問題，比如特征拼接錯誤，特征『時間穿越』等等。
這裏邊反應的壹個本質問題是特征處理流程的規範性問題。那麽我們是如何來解決這壹點呢，先，我們用在線代替了離線，通過在線落特征日誌，而不是RawData，並統壹了特征日誌Proto，如此就可以統壹特征解析腳本。