對于一個程序員來說，代碼就是他的另一半生命，如何寫出高質量的代碼是每一個程序員應該經常思考的問題。因為他關系到程序員個人價值的體現，工作績效，個人升遷乃至職業生涯發展；可能有人要反駁我說，我以后會走管理路線，寫不好代碼關系不大；我只能抱歉的說一句，你太天真了，你可以去看一下當下中國的軟件開發行業的項目經理有多少是從優秀的程序員升級來的，更有甚者，Manager本身就是架構師加首席程序員。如果你連你負責的代碼的質量都不能保證，老板如何放心的把項目交給你來管理。當然，我并不是說，做程序員就只要悶頭Coding就行了；而只是強調一點，做好本職工作，努力提高代碼質量，以此來提高個人工作績效，在同事和上司面前樹立你的個人品牌，才是一個程序員發展的正確道路。既然如此，那如何才能產出高質量的代碼呢？這里我僅僅發表一下個人的一些想法和感悟，供大家交流和參考：
1.充分正確的理解需求
對于Manager或Leader交給你的任務，你一定要知道需要實現什么功能，它的應用場景是什么樣的，最好用UML做出用例幫助你來加深對需求的理解。最重要的一點是，如果有不清楚的，一定要及時反饋，這個工作一定要做好，否則你的代碼質量再高，也是白搭。另外，如果你覺得可能有一些需求以后可能會有變化或提高，要做重點關注。
2.良好的可擴展的設計
需求弄清楚以后，別立即就開始寫代碼，至少你要有一個設計產出吧。用什么工具來表示你的設計不是一個大問題，除非項目有要求；UML圖可以，思維導圖似乎也行，最差可以在紙上畫出來吧，只要能表示你的設計思路，怎么做隨便你。在這里，我有三點經驗；第一，在需求可能發生變化的地方，一定要留出抽象的接口，如果你是Java程序員，那么就是指接口和抽象類；要是你是C++程序員，那么就是指虛擬基類；第二，不要指望一次可以做到盡善盡美，100%的把需求轉化為了設計。只要能做到80%，就可以開始寫代碼了。可能你會問，我怎么知道我的設計清楚的表達了多少需求，很遺憾，我也回答不上來，一切在你個人對需求的理解上；理解的越好，你就越能清晰的認識到你的設計究竟多大程度上契合了需求。第三，設計模式絕對是一個有力的武器，每個程序員斗應該去不斷的學習它；但是要用的好沒有別的辦法，只有在平常工作中有意識的去實踐，不斷總結積累，才能最大限度發揮它的威力。
3.迭代式的代碼編寫
有了設計，下面我們就要開始寫代碼了，這個過程是一個迭代的過程。首先，按照原始設計寫出代碼，在寫的過程中，你就會發現有好多問題在等著你，沒有關系，這些就是你最重要的東西，把他們一一解決并記錄下來。完成你的代碼后，自己做Review，對剛才記錄的問題做分析，你就會發現有的問題來自于需求理解不夠，有的則來源員設計的不合理，還有就是技術本身的限制。修改設計，重構原來的代碼，然后再發現問題，再分析，修改設計，再重構，直到你自己沒有發現什么問題，認為自己的代碼已經100%反應了設計，而設計也100%反應了需求。下來，你還要為你的代碼編寫單元測試代碼，保證代碼邏輯按照你的設計來進行；這一步后，還沒有完，接下來，你應該邀請同事和Manager,Leader一起來做Peer Review,讓他們對你的代碼的結構，可讀性，可擴展性，是否準確全面的反應了需求提出意見。對這些問題，大家進行討論，確定解決的辦法，然后你再去執行。一般，我在寫代碼時最少要進行兩次代碼重構才能結束這一過程。
寫代碼是一個艱苦卓絕的過程，只有通過不斷的努力，才能寫出結構清晰，可讀性強的優美代碼。在結束之前，我發表自己對于好代碼的外在表現的一些看法：
1.一個類只定義它該做的，方法不能太多，對外的方法不超過5個。
2.方法盡量簡短，要是超過了10行，你就可以考慮重構了。
3.要有相當數量的接口保證可擴展性。
4.類名，方法名，變量名要有意義。
5.詳細清晰的注釋。