代码质量管理实践-看得见的改进.ppt

1、代码质量管理实践看得见的改进,周凤波 焦点科技-平台架构部,内容,质量管理的必要性 质量管理实践 看得见的改进 总结,互联网开发特点,市场竞争激烈，需求变化快 开发周期长,隐性成本,时间/迭代,代码质量的影响,成本,生产率,质量管理实践,代码质量,质量,角度：演化、维护,高内聚、低耦合是有限度的,目标群体：开发人员,代码质量保障步骤,市场调研,优先级,需求,高,中,低,用例,统一编码规范,代码分析,单元测试,持续集成,代码评审,重构,代码质量保障步骤,迭代,代码评审,持续集成,对待变化的态度,不只是拥抱变化，更要利用变化,时间/迭代,质量,拒绝退化,重构的时机,某周一早上，你的老板要求编写一个

2、小程序，从键盘读入字符，然后输出到打印机上 void Copy() int c; while (c=Rdkbd()!= EOF) wrtPrt(c); ,Copy,Char,Writer Prt,Char,Read Kbd,重构的时机,几个月后，老板来找你，说有时希望Copy程序能从手写板读入信息几个月后，老板又来找你，有时希望Copy程序可以输出到U盘上,boolean ptFlag=false; boolean punchFlag=false; void copy() int c; while(c=(ptFlag?Rdpt():Rdkbd()!=EOF) punchFlag?wrtPunc

3、h():wrtPrt(c);,Read,Writer,Copy,Kbd,Pt,Char,Char,Prt,Puh,看得见才能Hold住,质量管理平台,Sonar Maven Hudson 插件体系结构,看得见的度量指标,代码,重复代码,单元测试,复杂度,圈复杂度 度量代码分支情况 If for while case catch throw return & | ? 复杂性越高，测试成本越高,复杂度,编码规则检查,注释,架构,依赖结构矩阵（DSM）,设计度量指标,LCOM4,Lack of cohesion of methods 说明类内部方法和变量之间的关系 指标 LCOM4=0/Bad LC

4、OM4=1 /高 LCOM4=2/低 SRP原则,RFC,Response For Class 通过检查方法被调用的情况来反映一个类的复杂程度 可以简单的理解为一个类所包含的方法多寡 复杂度从类的内部描述，RFC从类的外部来描述 RFC = M + R RFC = M + R M = number of methods in the class R = number of remote methods directly called by methods of the class R = number of remote methods called, recursively through

5、the entire call tree,设计,设计,高级度量,Sonar插件,/display/SONAR/Sonar+Plugin+Library/,插件,改进效果,改进,架构-模块划分原则,采用Maven多Project结构，先根据职能分Project，再根据功能模块分Package REP(重用发布等价原则) 重用的粒度就是发布的粒度 CCP(共同封闭原则) 包中所有类对于同一类性质的变化应该是共同封闭的 ADP(无环依赖原则) 在包的依赖关系图中不允许存在环,设计-变化应对之道,Martin Fowler的建议: 对象的三个视角,设计-变

6、化应对之道,在概念上层次上交流，在实现层次上执行，客户端无需准确知道具体操作细节，只需一般性（概念性）知道即可 只要概念不变，客户端就可以与实现细节的变化隔离开来 案例：下一节分享去哪里听,讲师,听众,焦点,公司A,主题A,设计-变化应对之道,Programming to an Interface, not an Implementation 客户对象和服务对象之间的职责分配 使用抽象类隐藏具体的实现 创建和使用分离 案例：评价、资料,讲师,听众,焦点,公司A,主办方,uses,uses,create,create,设计-变化应对之道,Favor object composition over

7、 class inheritance 但是设计模式中为什么继承无处不在？ 不要按照传统的方式来使用继承 用新的行为来特化现有的具体对象 案例：讲师分类,讲师,男,女,主题A男,主题B男,主题A女,主题B女,性别,讲师,主题,女,男,主题A,主题B,设计-变化应对之道,Designing for Change 在设计中思考什么应该变化，并封装会发生变化的概念 封装不只是隐藏数据，也可以是封装类型 变化不只是算法和行为，可以是任何事情 案例：委托评价,讲师,听众,焦点,公司A,主办方,uses,uses,create,create,公司B,设计-变化应对之道,Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle,注释,能用代码来阐述的，尽量不用注释 好的注释应该解释意图，而不是解释操作 什么也比不上放置良好的注释来得有用 什么也不会比陈旧、提供错误信息的注释更有破坏性,单元测试-FIRST原则,Fast（快速） Independent（独立） Repeatable（可重复） Self-Validatin