每当我们切入一个新项目时，我们发现项目中的文档总是少的可怜，而且里面的设计与当前的系统设计严重不符，有些甚至在架构上出现了严重的偏离。于是我们问待交接人，为什么项目中只有这么点文档，而且文档的内容也不准确？他们振振有词的告诉我们：这个项目的开发周期非常紧张，而且需求经常发生变化，他们根本没有时间去维护文档，里面的那份文档，是很久之前加班补的。要想看详细的设计，就去看代码吧，代码就是最好的文档。
听到这里，有些人也许会以为项目中的代码写的多么的酷，每个类都是按照教科书中的格式体去注解的。但当我们看完一个流程的代码之后，就开始喷血。代码中的注释就像食堂免费粥中的米粒一样稀少，而有些注释竟然是Todo体（Todo: YYYY年MM月DD日 Modified By XXX Invest some method to make it perfect）。看到这，我们恨死了那该死的代码就是文档。面对这样的项目，我们开始感叹，为什么大家就不能规范一下自己的代码呢？为什么不能多写点文档留给后来人呢？为什么当初要死要活的换项目？
在这个项目上经历了无数个日夜的摧残之后，终于有一天，我们要离开这个项目了。开始大喜，宴请四方同事，我们终于解放了，获得自由了。以后再也不用看这个烂项目了。于是开始准备交接工作，然后走人。
新来接手的同事看到项目上少的可怜的文档，开始发问： 为什么项目中只有这么点文档，而且文档的内容也不准确？我们振振有词的告诉他们：我们刚接手这个项目时，文档比现在还要少，而且都是错的。这个项目开发周期紧，经常加班，没有时间去整理文档。要看详细的设计，就去看代码吧，代码就是最好的文档。
代码就是文档，所有的程序员都听惯了这句话，也恨透了这句话。因为这句话，几乎伤害过每一个程序员。每当看到不严谨的注释时，心里总是会先把这段程序骂一顿，然后再开始骂写这段程序的人。我们总是觉得别人的代码写的不够好，而自己的代码写的很严谨。可是，当别人开始看我们的程序时，他们也总是把我们的代码骂一顿，然后再来骂我们。这就是典型的程序员相轻。
代码写的不好也就算了，可是偏偏又没有响应的文档，这叫人怎么可以忍受的了呢？每一个参与过敏捷开发的人，都知道项目的周期很紧，工作强度很大，在程序开发的某一个阶段，可能真的没有时间写文档。但是在项目的整个开发周期中，并不总是很忙的，如果想要写文档，肯定能找到时间的，如果说没有时间写文档，那就是找借口。即使真的在工作时间没有时间写文档，我们也应该利用自己的时间去把这些设计文档补上，这些文档不但对于后来人的理解有很大的帮助。对于自己来说，也是有莫大的帮助，这些文档能够帮助我们更好的理解这个项目。
作为开发人员，请不要抱怨项目没有文档。如果项目没有文档，我们应该及时的补上这些文档，并用这个好习惯去影响别人，并传递给别人。如果人人都不偷懒，认真写文档。那时候，项目就不再缺少文档，我们也不用苦苦去看代码，不用为代码就是文档而发愁。给别人铺路，就是给自己铺路。让我们严格要求自己，从传递文档开始做起，让程序员的世界越来越美好。
