可以采用这种模式： 1.文章修订记录中有“确认人”、“确认时间”字段，和“修改人”、“修改时间”字段一样重要 2.除了“确认人”和“确认时间”，还可以有一个字段：“此次修改内容的颜色”，若不同的修改同时存在，可以通过颜色来区分。一般情况下，这次修改用“红色”，待确认后改回“黑色”即可；但如果这次用了“红色”，而在这次修改确认之前，又有了新的修改，则新修改可以采用“蓝色”，对方确认了红色修改，则将红色部分改成黑色，对方确认了蓝色修改，则将黑色部分改回黑色，以保证不会混乱 3.一般情况上，在本次确认之前不会提交新的修改，这时只用一种颜色代表新的修改就可以了 4.重要的部分可以用粗体、斜体表示，但不能用颜色表示，以免与“新修改部分”混淆 5.接口模式约定了一定要说到作到，要不然就会造成更大的混乱
1.流程数据保存多久 2.业务数据保存多久 需求文档里的保存期限是从业务角度出发，“数据”用需求中的概念来表示 维护文档里的保存期限则从操作角度出发，“数据”指的就是具体的表、具体的文件等
1.业务用户看的 2.系统管理员看的 3.开发人员看的
1 引言 本文介绍了XX系统的功能需求。 本文读者为需求人员、软件用户、开发设计人员和测试人员。 1.1 参考资料 《XX系统_术语表》 2 功能简介
1 引言 本文介绍了XX系统的设计。包括领域建模和一些功能的实现思路。 本文的读者为设计人员、测试人员。 1.1 参考资料 《XX系统_术语表》 《XX系统_需求规格说明书》
J2EE系统中的数据文件可以分为两类： 1.编写代码时确定的 静态文件，只能由开发人员手动修改，相对固定。如企业内部网站主页上通过固定超链接引用的“请假单.doc” 2.系统运行时产生的 动态文件。这又可以分为两类： a.文件产生后，需要作为业务数据一直或长时间保存。如 BBS用户发贴时产生的附件文件。此类文件可称作 较持久的业务数据文件 b.文件产生后，即时应用，即时作废。如大流量I/O时为了减少内存消耗而临时存在的缓存文件。此类文件可称作 临时数据文件 这些文件应该放在何处？是否应该和 源程序中的其他物理实体(.class文件,jsp文件l等)杂揉在一起？ 个人认为这受到软构件部署（从开发环境发布到生产环境）和系统分布式运行的制约。以下按文件类别逐一讨论： 1.静态文件。这类文件可以当作代码，和class文件、jsp文件一样，不受部署方式和生产环境 的影响。比如说，部署时可以和class文件一样直接复制，如果系统采用分布式运营，这类文件在各机器上都可以保留相同的副本。因此静态文件可以与源程序杂揉在一起 2.动态文件。 a.较持久的业务数据文件。 I.在开发环境进行单元测试时可能会产生一些业务数据文件，这些文件不适于拷到生产环境，如果这类文件和源程序中的其他实体杂揉在一起，那么部署前就要先拣出来删掉，此举无疑增加了部署的复杂度。因此，此类文件不能和源程序放在同一个目录中。 II.此类文件往往被分布的各个程序共享使用，或者将来可能会被共享（如当前的单台WEB服务器以后可能要做集群）。因此，此类文件在就不应入在系统某一进程专属的机器上，而应放在一个独立于任何进程的机器上，如一个独立的FTP服务器，但这样做的代价是 额外添加了一个服务器的维护量，并影响物理架构 b.即时失效的临时文件 I.若考虑部署方式，应与 持久业务数据文件 的处理相同，即不应与源程序保存在相同目录中 II.若考虑分布式运营，应于此类数据文件为临时文件，不可能为多进程共享，因此与使用它的进程可以放同一台机器上，如c:\temp。不过，如果一个系统中既有持久业务数据文件，又有这种临时文件，为了让运维人员觉得清晰，仍可以考虑采用独立于任何进程的文件服务器。这样做的代价是加大了程序设计的复杂度（远程读写文件的代码比本地读写文件的代码要麻烦一些） 结论： 1.静态文件当作*.class,*.jsp文件处理， 可以与源程序杂揉在一起 2.动态文件 不能与源程序混杂，并视持久程度，决定是否要放在一个 独立于系统各进程的文件服务器中
环境划分对代码组织的约束 把软件从源环境增量地发布到目标环境时，必须确定源程序(jsp文件，classes文件，配置文件等)中哪些属于各环境相同的部分，哪些属于各环境不同的部分。对相同的部分，可以直接覆盖；对不同的部分，只能在目标环境手动地对照修改，以使目标环境的功能与源环境相同，同时又保留一些特定信息（如数据库地址）。 开发环境中如果尽量把各环境相同的部分集中放在一处，把各环境不同的部分集中放在另一处，就能使增量发布比较方便。
1.表结构 纯粹的表结构说明应该写在一个独立的《数据库设计文档》里 但是为什么要采用这些字段，为什么要这样设计表之间的关系，可能牵涉到一些设计思想。这些思想应该写在《详细设计文档》里 2.存储过程 有些同学可能把很多业务逻辑写在存储过程里，因此存储过程里要多写些注释。而且，如果存储过程里的业务逻辑跟其他程序有紧密联系，也应该在《详细设计文档》里写清楚。
在编程时，开发人员倾向于认为代码肯定是对的，不可能错，不用做单元测试了，或者只做个正例测试得了 但实际上，臭虫就是在这种情绪下滋生的， 尤其是牵涉到账务计算的金融系统。 这是教训，应该考虑把“是否编写单元测试用例或代码”作为代码审核的一个考核点。
今天同事小Q提出：除了开发环境和生产环境，再建一个测试环境。 开发环境散落在各开发人员的电脑上，如果直接在开发环境上进行测试，一些person-specific的东西可能会影响测试的准确性，于是就需要建一个测试环境，与开发环境相比，它的特征是消除了person-specific的特征，与生产环境相比，它不用承担生产上的风险 测试环境还有一个用处。向开发中的外部系统提供服务时，直接用生产环境进行联调是不合适，用测试环境就没什么风险了。因此，我们的产品上线后，测试环境仍要与生产环境长期共存、并保持开放状态