敏捷软件开发的一个常见的做法，就是将程序编写提升到软件开发的核心角色，这比很多软件开发通常的做法要重要的多。这部分是将代码归类为软件系统的主要文档（如果不是主要文档）。
我感觉需要立即反驳一个普遍的误解，即代码是唯一的文档，尽管我经听到极限编程的这个说法 — 我从来没有听到极限编程的领导人这么说。通常还是需要进一步的文档来作为代码的补充。
把代码作为主要的文档来源的理由是：代码是唯一足够详细并且准确的执行该角色的代码。Jack Reeves著名的文章“What is Software Design？”雄辩地指出了这一点。
这个原则带来的一个重要的结论就是：程序员需要在保证代码的整洁和可读性上下功夫，这一点很重要。说代码是文档并不是说特定的代码库就是一个好的文档。和许多的文档一样，代码可以是清晰的，也可以是混乱的。代码并不是天生的就比其他定的文档更易读。（其他形式的文档可能更让人绝望-我已经看到了很多混乱的UML 图）
当然大部分的代码库都不是好的文档。正如作为一个谬论，说把代码作为文档就排除了其他形式的文档。很多时候说代码是糟糕的文档意味着他们本身就是糟糕的，所以这是一个谬论。编写清晰可读的代码是可行的，我确信，大多数的代码都可以写的更加清晰。
我认为代码难以阅读的原因是因为人们没有把它作为主要的文档。如果不愿意让那个代码变得清晰，那么更没有机会将代码本身变得更清晰。所以让代码变得清晰的第一步要把代码作为主要文档，然后努力让他们变得更清晰。我认为这源于大多数开发人员在开始接触编程的时候所学的知识。我的老师并没有强调过要让代码变得更清晰这件事儿，他们没有重视过这件事儿，当然更不会去说如何去做这件事儿。我们整个行业都需要重视整洁代码的价值。
接下来就是如何去学，我在这儿给你提供一些畅销技术作者的建议-就像审查一样。如果没有读者给我的反馈，我觉得我从来没有想过会写一本书。同样，整洁清晰的代码比从别人那里获得是否容易理解比清楚的代码更加重要。所以，抓住每一个机会，寻找让别人更容易读懂你的代码的方法，找到他们容易理解的和困惑的东西。（是的，结对编程是一种很好的方式。）
其他的具体建议，我建议阅读一些编程风格方面的书。 Code Complete 是我的首选推荐，我也建议 《重构》，毕竟重构也会让代码变得更清晰和易读。重构之后，《重构与模式》（ Refactoring to Patterns）是一个很不错的建议。
你会发现人们总会有各种分歧，记住，代码库是团队所有的（即使团队内部对代码的不同部分分属不同个人），一个专业的开发人员需要改变他自己的风格，以反应团队的需要。所以，如果你喜欢三元运算符，如果你的团队觉得这是不容易理解的，那么不要使用它。你可以按照自己的风格在你的团队中编程，但是无路如何，你应该遵循团队的需求和规定。