Chen Jian

1.表结构 纯粹的表结构说明应该写在一个独立的《数据库设计文档》里 但是为什么要采用这些字段，为什么要这样设计表之间的关系，可能牵涉到一些设计思想。这些思想应该写在《详细设计文档》里 2.存储过程 有些同学可能把很多业务逻辑写在存储过程里，因此存储过程里要多写些注释。而且，如果存储过程里的业务逻辑跟其他程序有紧密联系，也应该在《详细设计文档》里写清楚。

在编程时，开发人员倾向于认为代码肯定是对的，不可能错，不用做单元测试了，或者只做个正例测试得了 但实际上，臭虫就是在这种情绪下滋生的， 尤其是牵涉到账务计算的金融系统。 这是教训，应该考虑把“是否编写单元测试用例或代码”作为代码审核的一个考核点。

    今天同事小Q提出：除了开发环境和生产环境，再建一个测试环境。    开发环境散落在各开发人员的电脑上，如果直接在开发环境上进行测试，一些person-specific的东西可能会影响测试的准确性，于是就需要建一个测试环境，与开发环境相比，它的特征是消除了person-specific的特征，与生产环境相比，它不用承担生产上的风险    测试环境还有一个用处。向开发中的外部系统提供服务时，直接用生产环境进行联调是不合适，用测试环境就没什么风险了。因此，我们的产品上线后，测试环境仍要与生产环境长期共存、并保持开放状态

个人认为，检验设计文档是否合格的唯一标准就是：     如果你辞职走人了，新人看着你的设计文档能不能迅速接手

就应该在行事之前先写好一个文档

43299.58

一、不合格式 1. 长度超过规定的最大值 2. 长度小于规定的最小值 3. 将非数值的字符串输入数值型字段中 4. 数值正负不合要求 5. 数值的大小超过规定的最大值 6. 数值的大小小于规定的最小值 7. 必填字段为空 二、trim   包括 left trim ,right trim, both trim 三、输入特殊字符   1. 使用单引号   2. 双引号   3. 百分号，下划线

     标准模板其实一点也不通用，那些奇怪的提纲只会限制你的思维和表达，没别的作用

    很多东西大家都很容易理解、但一直缺乏一个简短的名称，比如“一个申请件文件中的一行”，“申请了信用卡的人或者持有信用卡的人”。在写文档或者口头交流的时候，这些东西会多次出现，如果每次都用一大串的汉字描述，肯定会让人觉得很不方便；而且，这种汉字描述的风格受说话者的背景和状态的影响很大，可能某人叫“文件中的一行”，另一个人叫“文件中的一条记录”，或者上午叫“申请件文件”，下午就叫“进件”，这种不统一的叫法会让人觉得不明晰、有歧义，在讨论是可能要反复确认，从而影响交流的效率。

1.按四层体系结构组织：过程，阶段，活动，子活动（最小单元） 2.为本机构建立一个通用（标准）过程，在做具体项目的时候按项目需要对此过程进行裁剪。因此过程裁剪是一项重要的项目计划活动。 3.计划和计划的执行总是可以分开的，比如测试计划（用例）可以在编码前就写好。这样做的目的就是让计划和其他阶段可以并行执行