关于代码驱动开发的生产率问题

        类似于UML的用例图、类图、交互图、活动图等的图表，在当编码工作开始时，那些文档和相应的图表就慢慢地失去了它们的价值。随着编码阶段的进展，图表和代码之间的联系越来越弱。随着时间的推移，代码和图表之间就难以保持同步了，因为更新图表和文档的时间已经不是那么充裕了。而且，图表和文档是否有价值也成为有疑问的事情，既然新的变化最终体现在代码上，为什么还要花时间去做那些文档和图表。

    极限编程XP的思想的流行原因之一就是.因为事实上代码是软件开发的驱动力量，在开发过程中有生产率阶段的只有编码和测试。

    建模的支持者认为，编程者需要模型就如探索者对于地图的需要是一样的，没有它就失去了系统的蓝图，失去对系统的整体认识。在一些成熟的软件项目中，建模的工作仍然必不可少。但是，无论我们是否花时间去建模或写文档，不可否认的是，写代码才是最有生产率的工作。模型与生产率之间的问题成为传统开发的一道难题。

    在开发过程中，对文档的维护一向不为人重视，甚至是最后考虑的。大多数开发者认为他们的工作是编写代码，写文档既浪费时间又降低开发速度，而且对开发工作还没有多大帮助。对文档的维护经常是在所有的代码完成之后才会进行的。写文档更多的时候不是出于自愿，而是客观上的要求。这也是很多时候文档质量不高的一个原因，同时也导致了文档不能及时更新。

    虽然这些开发者的认识有所偏差，但是文档与代码之间的距离过大却是不争的事实。如果文档与代码之间有更直接的联系，甚至可以通过文档可以产生代码，这些问题
也许就容易解决了。