敏捷軟件開發的一個常見的做法，就是將程序編寫提升到軟件開發的核心角色，這比很多軟件開發通常的做法要重要的多。這部分是將代碼歸類爲軟件系統的主要文檔（如果不是主要文檔）。
我感覺需要立即反駁一個普遍的誤解，即代碼是唯一的文檔，儘管我經聽到極限編程的這個說法 — 我從來沒有聽到極限編程的領導人這麼說。通常還是需要進一步的文檔來作爲代碼的補充。
把代碼作爲主要的文檔來源的理由是：代碼是唯一足夠詳細並且準確的執行該角色的代碼。Jack Reeves著名的文章“What is Software Design？”雄辯地指出了這一點。
這個原則帶來的一個重要的結論就是：程序員需要在保證代碼的整潔和可讀性上下功夫，這一點很重要。說代碼是文檔並不是說特定的代碼庫就是一個好的文檔。和許多的文檔一樣，代碼可以是清晰的，也可以是混亂的。代碼並不是天生的就比其他定的文檔更易讀。（其他形式的文檔可能更讓人絕望-我已經看到了很多混亂的UML 圖）
當然大部分的代碼庫都不是好的文檔。正如作爲一個謬論，說把代碼作爲文檔就排除了其他形式的文檔。很多時候說代碼是糟糕的文檔意味着他們本身就是糟糕的，所以這是一個謬論。編寫清晰可讀的代碼是可行的，我確信，大多數的代碼都可以寫的更加清晰。
我認爲代碼難以閱讀的原因是因爲人們沒有把它作爲主要的文檔。如果不願意讓那個代碼變得清晰，那麼更沒有機會將代碼本身變得更清晰。所以讓代碼變得清晰的第一步要把代碼作爲主要文檔，然後努力讓他們變得更清晰。我認爲這源於大多數開發人員在開始接觸編程的時候所學的知識。我的老師並沒有強調過要讓代碼變得更清晰這件事兒，他們沒有重視過這件事兒，當然更不會去說如何去做這件事兒。我們整個行業都需要重視整潔代碼的價值。
接下來就是如何去學，我在這兒給你提供一些暢銷技術作者的建議-就像審查一樣。如果沒有讀者給我的反饋，我覺得我從來沒有想過會寫一本書。同樣，整潔清晰的代碼比從別人那裏獲得是否容易理解比清楚的代碼更加重要。所以，抓住每一個機會，尋找讓別人更容易讀懂你的代碼的方法，找到他們容易理解的和困惑的東西。（是的，結對編程是一種很好的方式。）
其他的具體建議，我建議閱讀一些編程風格方面的書。 Code Complete 是我的首選推薦，我也建議 《重構》，畢竟重構也會讓代碼變得更清晰和易讀。重構之後，《重構與模式》（ Refactoring to Patterns）是一個很不錯的建議。
你會發現人們總會有各種分歧，記住，代碼庫是團隊所有的（即使團隊內部對代碼的不同部分分屬不同個人），一個專業的開發人員需要改變他自己的風格，以反應團隊的需要。所以，如果你喜歡三元運算符，如果你的團隊覺得這是不容易理解的，那麼不要使用它。你可以按照自己的風格在你的團隊中編程，但是無路如何，你應該遵循團隊的需求和規定。