代码毕竟是人写的，不能保证一点错也不出，但是绝对可以通过方法来减少甚至杜绝这种情况的发生。
出现问题，一个正常的思维是什么呢？
先看看为什么会出现问题，然后针对这些问题，做一些针对性的改进，这次改进了不算完事，要保证以后也不会出现这样的问题，所以你就想了，能不能搞个规范的流程，大家都按着做，就不会出问题了。
小伙子，这个想法是很好的！
所以，大家聚在一起就把规范搞出来了，然后大家照做。
那怎么保证是按着规范做的呢？
做完以后，就得有个检查的过程，总结执行计划的结果，分清哪些对了，哪些错了，明确效果，找出问题。最后对检查的结果进行处理，成功的表扬，失败的总结教训。这就是一个解决问题的流程。
那么，从管理的角度而言，这就是PDCA戴明环管理方法。
P(PLAN)：从问题的定义到行动计划
分析现状，讨论出现问题的原因，确定最终的目标（就是以后不会出现低级问题）
比如，经常变量定义错误？逻辑错误？版本不对？未进行充分的单元测试、继承测试，等等。。。
为什么要讨论这个呢？
就是为了针对这些问题，对开发人员而言制订出开发规范，对项目管理人员而言制定出管理规范。
D(DO)：实施行动计划
就是执行落实上面制定的规范。开发人员执行既定的开发规范，管理人员依据管理规范监督开发人员执行情况。就是具体的行动方法。
C(CHECK)：评估结果
上一阶段规范已经不折不扣的执行了，但是执行完不是万事大吉，我们的最终目标是不会再出现之前的问题。所以，这一步就是确认实施方案是否达到了目标。效果检查，检查验证、评估效果；"下属只做你检查的工作，不做你希望的工作”， IBM的前CEO郭士纳的这句话将检查验证、评估效果的重要性一语道破。
A(ACT)：标准化和进一步推广
肯定成绩，把成功的经验尽可能纳入标准，进行标准化，遗留问题则转入下一个PDCA循环去解决。这个阶段就是解决存在问题，总结经验和吸取教训的阶段。该阶段的重点又在于修订标准，包括技术标准和管理制度。没有标准化和制度化，就不可能使PDCA循环转动向前。
