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