註釋的目的在於提高代碼的後期維護性，也就是說花費了當前的工作時間換取以後節約更多的時間。
一次性代碼、以後不需要維護的代碼實際上不需要寫註釋。
結構清晰簡單、很容易維護的代碼可以少寫甚至不寫註釋，寫多了註釋反而會降低工作效率。
代碼越複雜越不容易維護，維護的人越是參差不齊，越是需要認真寫註釋。
判斷註釋、文檔寫的夠不夠其實很容易驗證。如果代碼將來也還是自己維護，那就找找幾年前自己的代碼，看看是不是很容易看明白，思考一下如果想改點什麼功能是不是比較容易。我看過自己10年前的代碼，除了有些地方當時水平低寫的亂之外，都還比較容易看明白。如果代碼會有別的同事維護，就需要有制度互相驗證註釋、代碼是否清晰明白。
工程實踐總是複雜的。生活中我們遇到的問題實際上還要麻煩很多。
首先就是個人太短視，看不到或者是看輕註釋對未來的意義，或者是過於相信自己的理解能力，自己就不願意寫註釋。這種傾向比較難糾正，讓他多維護幾次很久以前寫的代碼可能有點幫助。
再就是因爲將來維護的程序員並不是自己，那麼寫註釋就變成了降低自己的成績提高他人的成績，這種事情要聖賢才能做好，我們普通人主動做這個實在是痛苦，只能藉助考覈制度來輔助。這種考覈制度並不容易實施，因爲註釋、文檔的效果很難量化，不太可能被領導理解，也不太可能被業務、產品等其他部門同事理解，所以除非確定未來的收益歸於本團隊，否則團隊自己並沒有動力在當前約束自己。
如果底層程序員變動頻繁，那就需要小組長一級對註釋情況進行管理，如果小組長自己也變化頻繁，那就需要更高一級管理者來約束。這樣推導下去，如果某一級管理層不夠穩定，無法獲取註釋帶來的未來的好處，而他的上一級領導又沒有合適的制度感知、補償這一部分註釋帶來的工作量的話，註釋這個工作就肯定搞不好了。
其實日常管理之中比較容易提升的也就是這一部分，根據具體情況，制訂合適的管理制度，這一部分是可以控制好的。
另外還有更糟糕的不願意寫註釋、文檔的理由，有人會故意讓代碼只有自己看的明白，別人很難看懂，這樣有助於提高自己的地位。這種人還是爭取早點發現，早點清除吧。