為什么程序員都不喜歡寫注釋？
大家好，我是啊粥。
今天我們來聊一下關于代碼注釋的問題，開始閱讀正文之前，你先想 3 個問題：
你平時寫代碼的時候會寫注釋嘛？
你的注釋是怎么樣寫的，主要都表達些什么？
你一般會在什么樣的代碼里寫注釋？
好了，我們正文開始。
首先，我個人剛開始寫代碼的時候，非常喜歡寫注釋，我一般會把代碼思路先用文字表述出來。然后分成 1 2 3 4 每一步要干什么，怎么干。
然后寫完之后開始在每個步驟下邊填代碼，這個時期我的代碼注釋量是非常高的。
但是后來隨著技術熟練程度的提高，以及代碼水平的提高，我的注釋量就逐漸減少了。
并不是我覺得自己牛逼了不用寫代碼了，也不是我想專門給后人挖坑，純粹是我覺得不太有必要了。
因為一方面我認為當你可以寫出相對比較好的代碼的時候，你的代碼就是你的注釋，你的命名、你的日志以及你的單元測試等等所有東西會共同構建成你的完整注釋，最終他們合在一起形成的注釋遠比你一字一句寫出來的注釋要更清楚更實用。
并不是只有 // 后寫的才叫注釋。
通常來說，我們去閱讀理解一段代碼，一般我們會有下面三種訴求：
這代碼是用來解決什么的問題的?
怎么使用這段代碼，有沒有什么注意事項？
這個代碼的實現細節(jié)是什么，它是如何運作的？
對于第一點來說，Why 是很重要的，但我們需要知道，【代碼注釋通常來說都是微觀的，不是宏觀的】。
對于宏觀的東西都會寫在需求和設計文檔中，那些微觀的 Why 如果能寫成注釋確實是挺好的，因為代碼再簡單再易讀也不會告訴你 Why，這一點上我還是非常認同的。
但同理，這個 Why 寫成日志好像也是可以的，比如：“正在解決 XXX 問題...”，你想想是不是這么個道理？
對于第二點來說，怎么使用這個函數，這個類，有沒有什么注意事項。
其實，我們需要的可能是一些示例，最好是可以直接拷貝復制后改一改就可以用的示例，畢竟大家都知道寫代碼的意義就在于是粘貼復制 
。
但是呢，這些示例完全可以寫成 Unit Test 單元測試案例，Positive 的案例告訴我們正常應該怎么用，Negtive 的案例告訴我們有哪些注意事項，不要這么用。
這比單純的代碼注釋要強數百倍，不是嗎？
難不成跟具體的例子相比，你更喜歡看一段話，告訴你：“請不要 XXX 使用這個函數”？
對于第三點來說，你要搞清楚代碼是怎么運作的，我們每個寫代碼的人都知道，注釋對于你搞清代碼是怎么運作的幾乎是沒有什么幫助的。
最好的方式就是打一些斷點，然后 Debug 一下代碼，看代碼運行時的那些 Context（變量里的值，狀態(tài)，條件，執(zhí)行路徑等）是什么樣的？
這時，注釋是低效的，把這些上下文打在 Debug log 里輸出才是最高效的。
生產環(huán)境可以選擇關掉 Info 或 Debug 級別的日志，然后開發(fā)的時候這些日志其實比注釋可能還好用（如果 Context 輸出比較全，且有規(guī)范）。
同時日志開關是自如的，完全可以由我們自己來進行控制，當你遇到 Bug 需要調試的時候你打開豐富的 Debug ，之后你可以再把他調回 Info 或者 Error。
我相信以上觀點可能很多人是不認同的，但是我說真的，作為初學者你肯定會有一個需要大量注釋的階段，主要是因為你經驗還比較缺乏，所謂沒有達到熟能生巧的地步。
但時，當你寫代碼寫的足夠久了之后，你會發(fā)現寫得好的代碼是自注釋的，代碼既注釋，而重要的地方才寫注釋，其實就是日志 ……
當然，還有一種情況我是建議寫注釋的，那就是二筆產品非要提一個不合理的需求導致你有一個不合理的寫法，這個時候我希望你能注明“不是我要這么寫的，是產品需求要求這樣的，我也沒辦法的”的無奈，免得下一任接受你代碼的人罵娘，說你是個菜雞。
好了，今天的內容就到這里了。
你也可以留言分享你寫注釋的一些經驗給到我們。
我是啊粥，關注我，我們一起向上生長。