對一幫新人在講代碼標準時，恰巧一位職位是領導的人進來視察，在講到關於註釋時，她很激動的強調要求寫很詳細的註釋來解釋代碼，而這正好和我講解的方向相反，爲此同其辯解了一番。
對話內容大概如下：
我：代碼的註釋還是越少越好。
領導：沒有註釋，我根本就看不懂這裏寫的是什麼，這是很差的代碼。
我：通過方法的名字，變量的名字，及代碼的執行順序就可知道。
領導：那不是要一層一層的看代碼，才知道，有了註釋，我直接看註釋就知道這是做什麼的了，也能很好的向領導，新人解釋代碼。
我：用代碼來代替註釋並不複雜。複雜的代碼通過不斷的抽取，優化成小方法，命名做到見名知義，根據邏輯組織方法的排列即可簡單明瞭。而註釋會有嚴重和當前代碼滯後的可能性，這時註釋反倒成了錯誤的指向。對於要看懂某段代碼在幹什麼，看這些方法的名字，變量的名字就知道在做什麼了。但你要想知道這個功能的根本原理是什麼樣的，那就需要一層一層的鏈接下去，仔細查看代碼纔行，靠註釋是沒有用的，註釋的壞處剛剛有講到，也不可能在每次用到某個方法時，就寫一大段的註釋詳細的解釋代碼的實現細節，其根本原理是什麼，這不是有點怪怪的。對於很多框架來講，他們並
不希望你去了解實現的原理是怎麼樣的，你只要知道調用這個方法會產生出什麼樣的效果來就可以了。你若真要想知道原理，那自己去看API，看代碼。同理，我們寫代碼也要做到這樣子。
領導：我還是不贊同。這樣我看不懂代碼，要不找副總問問，不要寫註釋好不好？要不你們來做設計好了。。。
我(無語，拿副總壓我)：我沒有說不要註釋，我只是說在關鍵的地方註釋即可，其餘的可通過代碼來代替註釋，看代碼也是有一定的門檻的。
。。。
真搞不懂，既然做設計那還看什麼代碼，要看代碼那就要掌握基本的框架，語言知識。想做設計，又要懂代碼，那隻能通過學習提升自身，纔是根本的解決之道。不想學習，只躺在資歷或過去經驗的基礎上，來要求別人寫出他們想要的代碼來是不可取的，殊不知知識早已更新換了好幾代了。不進必退，終究會被後人取代。
堅持每天的學習，與時俱進，纔會不斷的前進，才能立於不敗之地。成長起來，不要讓自己只是變老。