在開發中很多程式猿不喜歡寫註釋，或者寫的很少。我剛開始也是不怎麼寫註釋，但是後來發現過幾天后我都不曉得這段程式碼的意思了，有時還得跟一下程式碼。現在基本上公司都會規定開發人員寫註釋還會定期檢查，寫註釋是一個程式猿的基本操作，看沒有註釋的程式碼就像看外國電影沒有中文字幕一樣猜不到啊。對於不寫註釋的人來說我只有一句mmp不知該講不該講。

由於大多數程式設計師是團隊開發的，因此我想從團隊的角度解釋一下不寫註釋的危害。

不寫註釋，讓我第一個想到的居然是囚徒困境。

囚徒困境博弈論裡的一個經典悖論，現在我改編一下。碼農小A和小B合作一個專案。如果他們都寫註釋，每個人都需要開發6天。如果都不寫註釋，每個人要開發9天。如果一個寫註釋一個不寫，不寫註釋的需要開發5天，寫註釋的需要開發10天。

如果你是小A,會怎麼做呢？

從直覺出發，肯定是都寫註釋效率最高，因為兩個人都可以在第6天完成任務。但是，換個角度思考，反而是不寫註釋好一點，為什麼？

因為不管對方寫不寫註釋，自己不寫註釋一定是耗時最短的！

看似矛盾的結論，實際上可能引發一個惡劣的現象，就是大家為了自己的績效，選擇不寫註釋，這麼一來，從老闆的角度會發現整體效率降低了，因為都在給對方埋坑。

如果團隊裡只有一個人不寫註釋，會怎樣呢。他的效率會最高，因為只有他給別人埋坑，沒有別人給他埋坑。

因此，從老闆的角度，一定要強調程式碼規範。透過code review和程式碼掃描等機制，儘可能的把坑排掉，必要的時候甚至可以用一些管理手段，比如獎懲機制等。

當然，實際專案可能遠比我舉的例子複雜，可能有些模組或系統就是一個人開發一個人維護。這種情況依然建議把註釋文件啥的寫完善。一來，說不定某一天專案就會轉給別人維護。二來，不寫註釋，自己都會忘記自己的程式碼。

大家平時開發的時候寫註釋嗎，遇到不寫註釋的同事又要合作專案的時候怎麼溝通的呢？