程序員你為什麼這麼累續：編碼習慣之日誌建議

——請先閱讀這3篇文章:

程序員你為什麼這麼累？

我的編碼習慣 - 介面定義

我的編碼習慣 - Controller規範

開發中日誌這個問題，每個公司都強調，也制定了一大堆規範，但根據實際情況看，效果不是很明顯，主要是這個東西不好測試和考核，沒有日誌功能一樣跑啊。

但編程活久見，開發久了，總會遇到「這個問題生產環境上能重現，但是沒有日誌，業務很複雜，不知道哪一步出錯了？」 這個時候，怎麼辦？ 還能怎麼辦，發個版本，就是把所有地方加上日誌，沒有任何新功能，然後在讓用戶重現一遍，拿下日誌來看，哦，原來是這個問題。

有沒有很熟悉的感覺？

還有一種情況，我們系統有3*5=15個節點，出了問題找日誌真是痛苦，一個一個機器翻，N分鐘後終於找到了，找到了後發現好多相似日誌，一個一個排查；日誌有了，發現邏輯很複雜，不知道走到那個分支，只能根據邏輯分析，半天過去了，終於找到了原因。。。一個問題定位就過去了2個小時，變更時間過去了一半。。。

所以我對日誌的最少有以下2點要求：

能找到那個機器

能找到用戶做了什麼

針對第一點，我修改了一下nginx的配置文件，讓返回頭裡面返回是那個機器處理的。

nginx的基本配置，大家查閱一下資料就知道。簡單配置如下（生產環境比這個完善）

效果如圖，返回了處理的節點：

第二點，要知道用戶做了什麼。用戶信息是很重要的一個信息，能幫助海量日誌裡面能快速找到目標日誌。一開始要求開發人員列印的時候帶上用戶，但是發現這個落地不容易，開發人員列印日誌都經常忘記，更加不用說日誌上加上用戶信息，我也不可能天天看代碼。所以找了一下log4j的配置，果然log4j有個叫MDC(Mapped Diagnostic Context)的類（技術上使用了ThreadLocal實現，重點技術）。具體使用方法請自行查詢。具體使用如下：

filter中得到用戶信息，並放入MDC，記住filter後要清理掉（因為tomcat線程池線程重用的原因）。

用戶信息放入MDC：

log4j配置，增加用戶信息變數：

我做好上面2步後，對開發人員的日誌只有3點要求：

1. 修改（包括新增）操作必須列印日誌

大部分問題都是修改導致的。數據修改必須有據可查。

2. 條件分支必須列印條件值，重要參數必須列印

尤其是分支條件的參數，列印後就不用分析和猜測走那個分支了，很重要！如下面代碼裡面的userType，一定要列印值，因為他決定了代碼走那個分支。

3. 數據量大的時候需要列印數據量

前後列印日誌和最後的數據量，主要用於分析性能，能從日誌中知道查詢了多少數據用了多久。這點是建議。自己視情況而決定是否列印，我一般建議列印。

加上一篇AOP，最後的日誌如下：

其實日誌的級別我到不是很關注，還沒有到關注這步到時候。開發組長需要做好後勤工作（前面2步），然後制定簡單規則，規則太多太能落實了。

日誌這個東西，更多是靠自覺，項目組這麼多人，我也不可能一個一個給大家看代碼，然後叫你加日誌。我分析了一下，為什麼有些人沒有列印日誌的習慣，說了多次都改不過來。我建議大家養成下面的習慣，這樣你的日誌就會改善多了！

1. 不要依賴debug，多依賴日誌。

別人面對對象編程，你面對debug編程。有些人無論什麼語言，最後都變成了面對debug編程。哈哈。這個習慣非常非常不好！debug會讓你寫代碼的時候偷懶不打日誌，而且很浪費時間。改掉這個惡習。

2. 代碼開發測試完成之後不要急著提交，先跑一遍看看日誌是否看得懂。

日誌是給人看的，只要熱愛編程的人才能成為合格程序員，不要匆匆忙忙寫完功能測試ok就提交代碼，日誌也是功能的一部分。要有精益求精的工匠精神！

日誌規範想不到寫了這麼多，不容易啊。覺得有幫助請點贊加關注，其他規範敬請期待！更多內容請持續關注！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！