软件质量规范的想法
作为一线的开发人员，确实比较容易屈服于项目中的压力，往往被迫追赶进度而舍弃部分质量标准。
开发人员应该是自己要有主见的，好的质量除了和绩效有关系，更主要的是代表一个人的水平问题。
设计阶段
- 明确需求的侧重点，明确产品最终的期望值，避免做的过于简单或者是过于复杂；
- 多个方案里面挑一个出来，没有多个方案，很可能是没想清楚；
- 觉得方案不舒服，别扭，那肯定是有问题，
- 觉得太舒服太顺利，那得注意是不是想简单了；
- 设计之初，就想好测试，调试，验证阶段的工作怎么做？
- 项目中提交的评审，不要让流程拖太长时间，尽快评审完毕
开发阶段
- 仔细规划构建和集成的顺序，看下是否达到最优。一定保证整个开发流程是个“增量式”的集成，看下在目前的集成顺序下，是不是可以快速定位缺陷，瓶颈点是否最少，各个模块是否能高效并行的进行开发；
- 单元测试，今天check in的代码，是不是都做了冒烟测试？
- 未审核的代码，不要拖欠到1周以上，目前为止，见过最高效的缺陷检出就是代码审核了
- 代码规范，不是遵守，是要理解，不让你这么写的原因是什么？
- 尽量不要晚上下班前传代码，上库的代码要保证是完整的，干净编译的版本；
- 控制需求，控制时间，这个时候要避免进行中的东西没完整，又要开始新的任务；
验证阶段
- 测试方案也是需要设计和思考的，项目到后面往往会裁剪资源，资源有限的情况下也要将主要的问题都暴露出来