很多东西大家都很容易理解、但一直缺乏一个简短的名称，比如“一个申请件文件中的一行”，“申请了信用卡的人或者持有信用卡的人”。在写文档或者口头交流的时候，这些东西会多次出现，如果每次都用一大串的汉字描述，肯定会让人觉得很不方便；而且，这种汉字描述的风格受说话者的背景和状态的影响很大，可能某人叫“文件中的一行”，另一个人叫“文件中的一条记录”，或者上午叫“申请件文件”，下午就叫“进件”，这种不统一的叫法会让人觉得不明晰、有歧义，在讨论是可能要反复确认，从而影响交流的效率。
1.表结构 纯粹的表结构说明应该写在一个独立的《数据库设计文档》里 但是为什么要采用这些字段，为什么要这样设计表之间的关系，可能牵涉到一些设计思想。这些思想应该写在《详细设计文档》里 2.存储过程 有些同学可能把很多业务逻辑写在存储过程里，因此存储过程里要多写些注释。而且，如果存储过程里的业务逻辑跟其他程序有紧密联系，也应该在《详细设计文档》里写清楚。
摘自《The Pragmatic Programmer》 破窗户理论：一扇破窗户，只要有那么一段时间不修理，就会渐渐的给建筑的居民带来一种废弃感－－种职权部门不关心这座建筑的感觉。于是又一扇窗户破了。人们开始乱扔垃圾。出现了乱涂乱画。严重的结构损坏开始了。在相对较短的一段时间里，建筑的损毁得超出了业主愿意修理的程度，而废弃感变成了现实。 软件项目中也是这样： 如果你发现自己在有好些破窗户的项目里工作，会很容易产生这样的想法：“这些代码的其余部分也是垃圾，我只要照着做就行了”
测试管理过程 1.Define Test Requirements 2.Develop Test Plan 3.Execute Tests 4.Track Defects
标准模板其实一点也不通用，那些奇怪的提纲只会限制你的思维和表达，没别的作用
环境划分对代码组织的约束 把软件从源环境增量地发布到目标环境时，必须确定源程序(jsp文件，classes文件，配置文件等)中哪些属于各环境相同的部分，哪些属于各环境不同的部分。对相同的部分，可以直接覆盖；对不同的部分，只能在目标环境手动地对照修改，以使目标环境的功能与源环境相同，同时又保留一些特定信息（如数据库地址）。 开发环境中如果尽量把各环境相同的部分集中放在一处，把各环境不同的部分集中放在另一处，就能使增量发布比较方便。
程序中尽量不要用c:/temp作为临时目录，而应该一个代表具体模块的、较特殊的名字作为目录，如c:/tempDirForDownloadShanghai 否则的话，如果大家都不用特殊目录，那它们就会共享c:/temp作为临时目录 1.如果不同模块的临时文件名恰好也相同，文件之间相互覆盖的风险会大很多 2.在清理时也很麻烦，如果要删除模块A的临时文件，要先把它们从所有文件列表中先挑出来再删，不能整个地删