目录
所谓缺陷模式是指”程序中经常出现的错误或者导致程序出现异常的缺陷,这些缺陷有同样的产生原因、同样的表示形式,按照这些缺陷发生的规律能够提取出相同的缺陷模式“。总结为一句话为:过去的缺陷是未来犯同样错误的来源。
常⻅的问题例⼦:
在缺陷模型中,例如金融系统不能有物理删除,财务系统要用复式记账法等,没有遵循规则,就是陷入某一种缺陷模型。
应用缺陷模型要针对生产环境问题根源原因分析,我们会发现关键不在于分析混入阶段,而在于如何提出根源性解决方案。如果方案是流于表面的,那就会大概率没有效果。例如在生产环境数据库和测试环境版本比对,只有确保发布的DDL脚本是完整的、正确的,才可以达到预期的要求。因此,我们可以通过缺陷模型引⼊根源性预防措施,并且对⽣产环境的历史问题进⾏总结,进⾏深层次的根源原因挖掘,提出针对性的根源性解决⽅案,才能达到预防问题再次发⽣的⽬的。
找到共通问题的发现可以提出有效地解决⽅案,就可以避免同样的问题再次发⽣。
对过去的代码复查方式等,梳理出对应的质量缺陷模型,可以找到对应的根源性解决方案,进⽽提升代码质量。比如:金融系统不允许使用物理删除,记账需要采用复式记账法。
常言道:“上医治已病,下医治未病”。质量内建的意义在于是将质量在建的时候就实施进去,而不是通过复查、测试等事后手段。
在开发过程中,要求软件生命周期之间参与的各个角色都需要对软件的质量负责,这样可以确保软件在交付到下一环节前已经有了基础的质量保证。其核心目的就是减少因为质量问题导致的返工,避免浪费大量人力成本。
通过对BA⾯向对象知识的培训(包括SOLID原则以及设计模式的培训,全⾯提⾼需求分析、编程和代码书写⽔平能力),从书写代码上整理架构,并且保证用整洁的代码来书写,确保代码质量内建。
需求分析疏漏或者是错误是导致质量问题的重要原因。我们可以通过可视化软件需求分析⼯具箱,展现出更完整,更详细,更⾼效的⽅式分析需求。从源头开始内建质量,减少后续的开发、测试、集成阶段的问题出现的次数,从⽽整体提升软件⼯程的质量和效率。
案例:【这个个按钮是否可以按下?】一个按钮是否可以按下,可能由多个因素控制的,比如说:1. 角色2. 部门3. 状态
要如何描述这三者的组合才能够让开发明确需求?
错误的方向:
1.将所有的组合全描述很显然庞大且难以维护,
2.采用长长的 if-else来描述,会变成锯齿形需求,从而引导出锯齿形代码,而且会造成代码难以维护。
具体解决措施:
把这三个对按钮的状态影响分别列出:
角色:
管理员 √
审批者 √
普通用户 x
部门:
HR √
开发 x
财务 √
状态:
未申请 x
已申请 √
审批通过 x
审批拒绝 x
这三者共同对按钮是否可以按下产生影响,在某个条件下,一个角色,一个部门,一个状态,共同决定了这个按钮是否可以按下,那么判定逻辑就是该角色可以按下 而且 该部门可以按下 而且 改状态下可以按下 该按钮这样就无须列出所有的组合,而是通过分别列出各自的条件,并且通过”&&”来连接计算,就可以得到完整的结论。这种方式是解耦合的方式来分析需求,要点是分离关注点。
进⾏全⾯的编程知识提升,以确保能够在书写每⾏代码的时候都是保证在质量内建,⽽不是功能堆砌。包括设计模式的应⽤,充⾎模型的应⽤等具有实战意义的代码书写技巧,从根源上杜绝烂代码,全⾯提升代码的质量,从⽽达到质量内建的目的。例如:下图是一个状态模式的类图。
解决各种典型代码问题,从⽽提升了开发⼈员在代码书写⽅⾯的实操能⼒,可以通过若⼲类典型常⻅问题的解决来⼤幅度提升开发能⼒,避免了很多不必要的时间浪费。并且要学会聚焦在常⻅的⼤⾯积发⽣的问题上提供解决⽅案,以同时提⾼效率和质量,产⽣直接的改进,比如说用Annotation代替if-else代码等。