軟體開發人員該如何深入理解自己的代碼

我最近碰到一個讓我很蛋疼的事情。一個C#程式員很自豪的宣布，說自己已經看不懂他一個星期前寫的代碼了。說實話，我真想知道他有什麼可值得驕傲的，我完全搞不懂嘛。他自豪的是，他每天寫了很多很多代碼？還是任何人都願意給他錢，讓他寫代碼？

對於此事我的觀點是： 對於一個職業C#程式員來說，不能理解你在一周前或者一年前寫的代碼是一件不可原諒的事情。

是的，我是麼說的。容我說明一下。我把軟體開發作為職業 已經有15年了。在較早的時候我接受了一些軟體開發信條，它們至今還伴隨著我。我依然可以很容易的理解我一年前、兩年前、或者十二年前編寫的代碼。無論它以什麼語言編寫，無論你稱其為域、演算法、分析器、網路應用、內嵌控制器、指令碼、連接器或者其它的什麼。哪怕是更早的代碼，即使對我來說難以理解，我也能辨識出當時已經開始出現的某些模式。

其實，讓自己讀懂自己以前寫過的代碼這事，目的是 要讓代碼具有可讀性。無論是你自己還是別人。 代碼失去可讀性，就像代碼不能正常工作一樣糟糕，或者比這個還糟糕。如果你自己在一段時候後都不能讀懂你寫過的代碼，那麼對於其他人來說，讀懂你的代碼更是不可能。

對於我來說，強調輕鬆的閱讀和理解你的程式碼是是如何的重要，不僅因為它是一個更好的產品，別人維護的，而且你的程式源碼是在你個人的工具箱中，在你的 職業生涯中，你將使用和重複使用它。並且這個工具箱特別授權，對於一個有經驗的程式員來說是一個最顯著地特點之一。我不能指望我的問題能夠立即被解決，面 臨著在過去有類似的東西，挖掘我自己的代碼檔案，找到一個解決的方法，或者相類似的問題。很顯然，你不能將無法理解的代碼放在你的工具箱中。

如果完成後至少沒有試圖解釋如何可以實現這一壯舉，這將是不公平的。坦率地說，這是不容易的表達清楚的，但我可以嘗試。

我可以肯定，這一點主要針對作家（嗯，也許也包括他創意相關行業）。當你敲下了幾行代碼（越短越好），你最好駐足於此，用一點點時間來檢查這段東西是否能 夠讓人理解。多讀幾遍，不要怕麻煩。想一想，假設自己是第一次看到這段代碼，還能理解不？如果悲劇的發現不可以……為啥？不要猶豫，一定要將“可讀性”作 為代碼品質的衡量標準，堅持下去，直到你的整段代碼都是可以理解的。

一旦你因為這些結果尋得樂趣，繼續再讀一遍，過幾天再讀一遍，這提醒我寫更有技術含量的部落格文章：我寫的每一個句子都要反覆斟酌20幾遍重寫5變，通常也是我寫代碼的事實情況，通過與生俱來的天賦和不斷的實踐反覆的練習獲得完美，由於我沒有前者，所以我只能靠後者來實現勤能補拙。

最後，是重構和大膽的完善。如果你遇到一段可以被寫的更加清晰的代碼，那麼就讓它更加清晰易懂吧。提高代碼品質是我們分內的工作。他的好處有的時候很難被量化，但是如果你參與了一兩個那種很多人蔘與，耗時很久的大型項目之後，你就會自然而然的明白了。