關於日誌列印的幾點建議

2021-10-02 03:52:23 字數 1869 閱讀 7749

日誌的列印在軟體開發過程中必不可少,一般分為兩個大類:

系統日誌:主要針對的是軟體開發人員(包括測試、維護人員),也就是說這部分的日誌使用者是看不到的,也就是我們通常所說的debug日誌。

操作日誌相對比較好理解,使用者做了什麼就記錄什麼;而列印系統日誌則很多人無從下手,往往一般有下面幾個方面:

where:不清楚在何處列印日誌

who:不清楚列印什麼級別的日誌

what:不清楚日誌應該包含什麼內容

where

1.程式入口

在入口列印日誌是因為這個時候傳遞進來的引數沒有經過任何處理,將它列印在日誌檔案中能一眼就知道程式的原始資料是否符合我們的預期,是不是傳遞進來的原始資料就出現 的問題。

2.異常捕獲

在異常列印出詳細的日誌能讓你快速定位錯誤在**,例如在程式丟擲異常捕獲時,在平時我們經常就是直接在控制台列印出堆疊資訊e.printstacktrace(),但在實際的生產環境更加艱苦,更別說有ide來讓你檢視控制台資訊,此時就需要我們將堆疊資訊記錄在日誌中,以便發生異常時我們能準確定位程式在**出錯。

3.重要資訊

這一點可能很寬泛,因為不同的業務邏輯重點可能並不一樣,例如在有的重要引數不能為空,此時就需要判斷是否為空,如果為空則記錄到日誌中;還有的例如傳遞進來的引數經過一系列的演算法處理過後,此時也需要列印日誌來檢視是否計算正確。但切記,盡量不要直接在for迴圈中列印日誌,特別是for迴圈特別大時,這樣你的日誌可能分分鐘被衝得不見蹤跡,甚至帶來效能上的影響。

who

日誌列印通常有四種級別,從高到底分別是:error>warn>info>debug。應該選用哪種級別就是個很重要的問題。

首先明確日誌級別中的優先順序是什麼意思,在你的系統中如果開啟了某一級別的日誌後,就不會列印比它級別低的日誌。例如,程式如果開啟了info級別日誌,debug日誌就不會列印,但不列印不代表不產生,通常依舊會記錄在檔案內容中,這在後面會提到。通常在生產環境中開啟info日誌。

以下是我的個人理解:

info

程式入口,這能讓開發人員確認引數是否為自己所為。

計算結果,測試關心的程式的輸出結果是否符合預期,那麼對於計算過程不應該關心,僅給出計算結果就能判斷是否符合預期。

debug

對於debug級別,我認為更關心的是過程,以及更為具體的相關資訊,因為幫助它的定位在於幫助開發人員定位bug,定位bug就需要較為詳細的引數資訊才能定位。例如對於某個具體的演算法過程,可以使用debug列印,開發人員不僅關心結果,同時在結果不正確時應該能根據debug日誌查詢計算過程是否出現偏差

warn

某個不常走到的分支,對於常規的操作是不應該列印warn日誌的,只有在滿足某個條件才能走到的分支,且這個分支引起了「警覺」,此時就應該列印warn日誌。

error

毫無疑問出現錯誤,程式不能繼續執行下去就應該列印error日誌,這個錯誤並不是業務上的錯誤。例如,新增某個使用者發現已經存在時,此時雖然新增失敗,但不能說程式出現錯誤就列印error日誌;在刪除某個使用者發現使用者已經被鎖定時,此時也不能說因為程式不能按照刪除的邏輯繼續執行下去就應該列印error日誌。

what

應該列印什麼內容?列印的內容一定要從實際出發。也就是說如果在實際的生產環境中,你的使用者量很大,日誌在不停地重新整理,如何定位某個使用者的整個登入以及後續的操作呢?當然就是根據使用者名稱來跟蹤。所以列印內容的第一要素就是要能便於定位;定位過後也許使用者在好幾個模板中進行操作,還是定位,這個時候定的是模組的位;還有一點當然就是使用者操作時的具體引數;最後一點就是使用者幹了什麼。

總結就是,[id, module, params, content](關鍵字,模組,引數,內容)。

以上就是對日誌列印的幾點建議,說的不全面,拋磚引玉。

關於專案管理的幾點建議

寫給未來的自己看,文件逐步更新中。當前國內企業都面臨的相同的問題,專案周期短 需求變化多,為了占領市場都要求專案能夠短 平 快,這樣給專案 管理帶來了很大的挑戰,從我經歷的幾個專案來看就是遇到了這些問題,也在這些問題上了很大的虧,今日得閒將之前 的經驗教訓進行一次總結。一 正常,按照專案計畫上線的專...

關於裁員幾點看法及建議

最近網易裁員事件引起廣泛關注,昨天網易針對此事,也發了宣告,到底誰對誰錯,孰是孰非?我們作為吃瓜觀眾實在是知之甚少,所以不敢妄下定論。身處軟體開發這個行業,近一兩年來,對於企業裁員雖早已是司空見慣,但每當看到被裁的遭遇,難免有種兔死狐悲的同情,憤懣不平之餘,我們是否可以從別人的不幸中,得到點啟發呢?...

UIImage的幾點建議

兩種初始化方式 1 uiimage imagenamed 適合 ui介面中反覆使用的貼圖,因為會儲存在 cache 中,所以速度會有保障。但是對使用次數較少,較大時候,不應這樣採用,因為會占用大量的 cache。2 uiimageimagewithcontentsoffile 直接從檔案中讀取,儲存...