以上五个是我认为重要的，我觉得是项目开始进行管理的阶段必不可少的；而下面几个，则是大家视情况可选的。

　　6、核心类图。这个可能是可选的，因为有时候，类的关于没那么复杂，也没有必要有这个图；相反，则需要进行记录。

　　7、数据库设计。数据库设计文档可能在review的时候用到。

　　8、系统间接口图。如果产品有若干个子系统，如web service等等，那么我认为需要一个描述系统间接口和交互关系的图，这个图应该在设计的早期开发出来供大家使用并且随时保持更新和关注。

　　有了文档和工具，是不是一切OK了呢？不对，像大而全的文档并不能帮助我们成功一样，有了文档并不代表项目能成功，如何维护和使用这些文档和工具是相当重要的。每个文档都应该有人去维护，那么谁去做这个事呢？我认为项目经理应该经常拿着功能说明书开会，它也可以被看做是WBS的初级版本，可以被标注状态和优先级；所有人都应该熟悉流程图，并随时提出对流程图进行检验和review；应该指定一个人负责构建，这并不需要花费很多时间，但是需要细心和一些完美主义精神；测试人员自然要维护好测试用例；每个人特别是开发人员，都应该有一种觉悟，那是一旦想起了哪些重要的逻辑，不管是业务的逻辑还是系统的算法，都应该记录到bug管理工具上。Bug管理工具完全可以记录这些零散但却重要的东西，以便将来方便查询。

　　在这里我也是根据自己的经历简单的谈了一些我的看法，这并不是金科玉律，我还得说，合适你的才是好的。

　　四、代码规范的选择

　　做开发不可避免的遇到代码规范，从上学时会学习到一些规范，但是每个公司都不同，那么我们到底要遵守哪些规范呢？我个人认为，一个合格的程序员应该可以随时调整自己适应任何一种规范，这是一种职业素养和能力。而何时该遵循何种规范，这也有一定的原则。

　　1、在现有系统（代码）基础上进行开发。这种情况下，我们应该尽量的去遵循原有系统的规范，不论是命名还是注释。因为如果这时你非要按照自己的习惯写，那么系统会出现两种完全不同风格的代码，这对将来的维护是一种噩梦。但是，遵循原有规范不是迁原有错误。如果发现原有的规范会造成一定的问题，要立刻改正，不能装傻充愣假装看不见。

　　2、新建团队开发新的系统。新建的团队中团队成员可能来自不同的环境，对规范的选择倾向一定是不完全一样的，此时要怎么做呢？这时，项目的应该组织大家一起做一个决定，讨论如何定义变量，如何给控件取名等等。在出现意见不统一又谁都说服不了谁的情况时，项目经理应该做出明确的决定。此时选择一种规范远比同时迁两个人要来的好，不然造成新系统中存在两种规范，同样是维护的噩梦。

　　3、稳定团队开发新的系统。这种情况容易得多，团队稳定后团队成员渐渐的了解了互相的习惯，互相学习后更容易达成妥协。只要注意让新加入的成员适应可以了。

　　有人可能觉得代码规范没什么大不了，功能正确没有bug不行了？当然，如果没有bug那肯定没问题，然而一个系统运行到退休还没有bug，哪位见过呢？我做了一些运维工作之后才渐渐了解到，不同风格的代码读起来像是一会儿在赤道，一会儿在南极，非常的痛苦，有时甚至会造成系统很多的不一致，大大增加了维护的工作量。我们的目标之一不是增加系统的可维护性吗？