最近遇到一個事情讓我大為不解。一個程式設計師自豪的宣稱他完全看不懂自己一週前寫的任何程式碼。我真的想探明他的這種自豪感從何而來，但無解。他是在驕傲每天寫如此多的程式碼嗎？有人會願意聘請這樣的人去寫程式嗎？
首先讓我明確的闡明我對此事的觀點：不能理解一週前或一年前自己寫的程式碼，這對一個職業程式設計師來說是不可饒恕的。
我就把話放這。現在，讓我詳細的說一下。我已經兢兢業業的程式設計編了 15 年。很早我就接受了一些程式設計習慣，至今沒有改變。我能輕鬆的看懂我一年前寫的程式碼，甚至 2 年前，12 年前。各種語言的程式碼，在各種業務領域裡。演算法，解析器，web 應用，嵌入式控制器，指令碼，連結，所有你能想到的。即使有些很早的程式碼，理解起來有些困難，但我仍然能從中看出一些模式的影子。
我能做到這些，主要的方法是認識到程式碼必須易讀。自己易讀，別人也易讀。程式碼如果不可讀，那就會跟不可用的程式碼一樣糟，甚至更糟。如果一段時間後你看不懂你自己寫的程式碼，別人就更不可能看懂了，沒有這種可能。不會有任何一個軟體產品會因為你而值得驕傲。
我無法用更大的聲音強調，讓自己的程式碼易讀、易理解是何等的重要。不僅僅是它能讓你的軟體產品更好，更容易被別人維護，同時，這些程式碼也將成為你自己的私人工具箱，你將會在今後的職業生涯裡使用、反覆的使用它們。擁有這樣一個工具箱，你將變得超級的強大，這將是你區別於其他程式設計高手的重要特徵之一。我己經記不清有多少次，當面對一些似曾相識的問題時，我通過回憶，在我的歷史程式碼庫裡搜尋，輕鬆快速的就能找到或整編出問題的解決方案。很顯然，你不能理解的程式碼是進入不了這樣的工具箱裡的。
這樣結束這篇文章似乎有點玩世不恭，我應該解釋一下是如何練就這樣的功力的。坦率地說，這很難用文字描述，但我盡力。
我非常確信，我的這種方法也被作家們(以及任何從事創新性職業的人)使用。一旦你寫完一段程式碼(越小越好)，你需要停下來，看看它是否易讀、易懂。讀它，反覆的讀它數次。跳出你對這個問題熟知的環境，想象那些完全不知道上下文情況的人在讀這段程式碼。這樣的一個人能讀懂嗎？如果不能，是因為什麼？從你的由《程式碼大全》等好書豐富而成的“程式碼可讀性”百寶箱裡找出所有可以的技巧，應用它們，直到你確信這段程式碼變得易讀為止。
一旦你滿意了，再讀一遍。幾天後再讀一遍。這讓我想起了我寫一些高深技術的文章時，每一個句子，我都要讀上 20 遍，重寫 5 次。我寫程式碼也經常是如此。完美可以因天賦而成，也可通過無情的重複和實驗實現。因為我不具有前者，我就一直堅持著後者。
最後，重構，無畏的改進。如果你遇到一段可以更清晰的程式碼，那就讓它更清晰。改進程式碼質量是我們這種職業中一種難以把握的附加任務，但當你遇到一個持續一、兩年，涉及多人的大型專案後，你自然就會領悟其重要。