談談程式設計師最討厭做的事
你們猜猜，作為程式設計師你們最討厭做的事是什麼？產品經理頻繁修改需求？不是。測試天天給你提交不可理喻的 bug ？也不是。接手別人交接的如火星文一樣的爛程式碼？其實也不是。
其實我搞了一個文字遊戲，叫最討厭做的事，而不是最討厭的事，上述幾點，可能是你最討厭的事，但是你又可能不能不做。有一種令人髮指的討厭就是你討厭別人不去做，而自己又毫無察覺的在犯這個錯誤，卻心安理得，而程式設計師在什麼情況下，才會這樣做呢？
程式設計師最討厭的四件事：
寫註釋、寫文件、別人不寫註釋、別人不寫文件。
不錯，今天我們就來談談程式設計師最討厭做的這件事：寫註釋。
程式設計師該不該寫註釋？
其實對於寫註釋這件事來說，還是有一定的爭議的，爭議其實不在於該不該寫註釋，而是在於不要過多的寫註釋，註釋多了，反而會讓你感覺整個程式碼比較混亂不堪，影響視覺。而且有人為什麼不太鼓勵大家過多的去寫註釋呢？因為程式碼即註釋，何為程式碼即註釋？程式碼是具有自解釋功能的，高質量，命名規範的程式碼，其實程式設計師應該一眼就能夠看懂這段程式碼的功能作用是什麼？
所以，程式設計師到底該不該寫註釋？要我說：該，但是要注意分寸。
如何注意分寸？
優秀的程式設計師可以少寫註釋
優秀的程式設計師都是懶的。因為懶，他才會寫出各種各樣的工具來替自己幹活。因為懶，他才會想辦法避免去寫無聊重複的程式碼——因此避免的程式碼的冗餘，削減了程式碼的維護成本，使重構變得更加容易。最終，這些由於懶惰激發出的動力而開發出的工具和最佳程式設計實踐方法提升了程式碼和產品的質量。
上面我們說了，程式碼即註釋。作為一個優秀的程式設計師，他們懂得註釋不是用來翻譯程式程式碼的，用程式碼能說清楚的東西，就自然不用費腦子去寫註釋了，集中精力寫出最優雅、高質量的程式碼才是首要的。程式碼是具有自解釋功能的，如果你寫的一個函式方法，命名非常規範，有一個好的方法名，裡面有很多可讀性很強的好的變數名，函式裡程式碼又不是特別多，最多二三十行。別的程式設計師一眼就看懂了，知道這個函式的功能作用，這就是程式碼的自解釋功能。這就告訴了我們命名的重要性，如果你能夠做到你的命名能完全、準確地描述所代表的事物和功能，這無疑提高整個專案程式碼的可讀性，可以不寫註釋。
但是如果一個函式上百行程式碼，甚至更多，還是需要寫一定的註釋的，甚至在一個重要的業務邏輯處理的地方，還是需要註明一些註釋的，畢竟時間久了，業務邏輯不熟悉了，看程式碼確實有些費勁。在重要的業務邏輯程式碼面前，還是需要一定的註釋。當然在命名的時候，再優秀的程式設計師可能也會遇到所命名的方法和函式，並不能準確代表所起的功能，這時寫註釋就很有必要了。記住：與人方便就是與己方便。
初級中等程式設計師還是得寫註釋
作為一個入門，初級或者中等的程式設計師，在自己程式碼質量不高的階段，時刻提醒自己養成一個好的寫註釋的習慣還是很有必要的。人不可能天生就是寫程式的料，也不可能一開始馬上就能夠寫出符合規範的高質量的程式碼。所以，前期記住一定得寫註釋。
為什麼很多程式設計師不願意接手別人寫的程式碼，是因為有一個問題就是必然存在的。每個人的編碼風格不一樣，命名方式和規範不一樣，這就是作為初級和中等程式設計師最容易犯的錯誤。其實每個公司都應該有自己的程式設計規範才可以。由於程式設計師程式碼的個性化，就造就了程式碼的多樣性。再加上沒有註釋，誰還願意看？
我感覺作為一個程式設計師，都應該有一個強迫自己寫出高質量程式碼的習慣，多讀讀系統原始碼，別人的開原始碼，看看高手都是如何寫函式，做封裝的。慢慢的，一步一步的去改善自己的寫程式碼的質量，慢慢的嘗試在感覺自己程式碼質量比較高的時候，讓你同事看看，如果沒有註釋，他能看懂了，那這裡就少寫註釋，或者嘗試不寫註釋。
為什麼談這個話題
談這個話題的原因
對，為什麼談這個話題呢？因為有很多程式設計師寫程式碼總有一種非常非常不好的習慣，那就是一段程式碼不用了，註釋掉，但是他心裡還總想著感覺這段程式碼以後可能還會用。所以就留著，不刪掉，但大多數情況下，過幾天就忘了，結果程式碼裡到處都是註釋，沒有一句是有用的。
接下來好了，接手的讀程式碼的人也不敢刪，一直留著，留著，留著，留著……直到永遠。
你們大聲告訴我，你們是不是有這種習慣？是不是有這種心理？
註釋維護
我想說，註釋也是需要維護的。很多人都沒有意識到註釋維護的重要性。怎麼說呢？不寫註釋坑人，比不寫註釋更坑人的就是寫了註釋，功能變了，不修改註釋的人。比如：
今天是程式設計師小王寫了一個處理業務邏輯的功能方法，功能是炒菜。過了兩個月後，需求變了，人家客戶不喜歡吃炒菜，需要換成了煮菜了。這時程式設計師小陳就在炒菜的功能方法上直接修改了，把功能改成了煮菜。但是註釋上寫的還是炒菜。又過了兩個月，客戶需求又變了，客戶吃膩了煮的菜，要求改成蒸飯。這時專案經理說：小郭，你把那個煮菜功能給我換成蒸飯。這時，程式設計師小郭，找啊找，找遍了註釋，發現沒有煮菜功能，一氣之下，算了，自己寫吧，自己又寫了一個蒸飯的功能函式。之後帶有炒菜註釋的煮菜功能，在接下來的一個又一個程式設計師都不敢刪，也不管了。
看到了，註釋不維護，是不是很不好。這只是其中一個方法，如果你修改了大部分的方法，又沒有修改註釋，接下來接手的程式設計師又不敢亂動，還看不懂，自己又重新寫，程式碼冗餘，混亂不堪，之後越來越爛，程式碼越來越沒人管了，也不想幹了。
總結
程式碼即註釋，寫註釋要注意分寸。如下：
-
用高質量的程式碼代替註釋。
-
在複雜函式和重要的業務邏輯面試，還是必須要寫註釋的。
-
註釋需要維護，不是寫了就好。不維護，還不如不寫。
-
要學會命名，遵守規範，這樣才能夠培養出好習慣。