Code Craft

Q&A
谢谢!
35
22
阅读书籍—
• 第三章
其他
代码的质量管理
25
Can You Find Bug？
NPE 错误(NullPointerException)
1990年1月15 导致纽约市电话系统停机9小时的软件故障就是这个break原因。 Software Engineering Notes
内部质量管理的四个”现代化”
Code Craft(编成艺术) The Practice of Writing Excellent Code 优质代码的实践
2014-11-11 沈栋
讨论的课题
代码是有味道的 编程价值观 高质量函数 代码重构 代码质量管理
1
代码是有味道的 ?
2
设计
3
别人眼中的代码
4
质量取决于短板
–确定需要修改哪些部分有多难 –必要的改动有多少 –实现改动对系统的影响有多大
19
建议
• 1：必须要求每人写一个小的培训总结（哪怕5条）。 参见附件，其他公司培训的一些总结。我一直 坚信，培训更多的是反思，通过3天的培训，学员必须有一些思考。 • 2： 你们开个部门讨论会，主要是一些项目经理和技术骨干(最好10多个人就可以)大家讨论怎样去实 践， 有哪些具体的想法。 • 3：对现在的代码进行分析，找出几个，非常恶心，超级变态的 代码。（比如最长的函数，最大圈复 杂度，大量的重复代码等） 让大家看到，目前代码质量腐烂到触目惊心。 • 4：推荐阅读， 几本书籍。 重构全书，代码整洁之道 第1章 代码大全 5-18章。 修改代码艺术 等等. 你们也可以做一些读书分享会， 1周1次，1次1～2小时。 • 5：你们选择5个最不能容忍的 指标， 绝对可以量化。 比如函数长度， 圈复杂度， 嵌套层次， 类的 总长度等。 • 6：结合你们的代码分析工具，进行查找。 新的函数，不要违反. 遗留代码作为不良资产可以不管。 • 7：每周1次，一个小组为单位，每次1小时的代码评审， 或者代码修改分享。 • 8：逐渐建立代码管理制度。
•量化-可度量 •工具化-可视化/透明 •自动化--•优化----持续改善
面向对象度量—高质量程序设计艺术
• 类的加权方法数(Weighted Method per Class，WMC)度量计算类的方法的总 数，并根据方法的复杂度给各个方法加上权重。 • 承树深度(Depth of Inheritance Tree，DIT)度量用于测量每个类从对象层次的 顶部开始的继承级别。 • 类的子类数(Number of Children，NOC)度量仅测之测量了类的直接子类的个 数，它为我们提供了三方面的基本知识真真 • 对象类间耦合数(Coupling Between Object Class，CBO)度量表示与给定类 有耦合的类的个数. • 类的响应( response for a class，RFC)度量测量的是在这个类的对象收到某 个消息（当这个象的某个方法被调用）时将被执行的不同方法的个数。 • 聚缺乏度(lack of cohesion in methods,LCOM)度度量，它计算了类中没有通 过共享类中某些字段相关的方法集的个数。
11
编
程
价
值
观
12
编程的价值观
• 价值观是编程过程的统一支配性主题： – 沟通——珍视与他人沟通的重要性； – 简单——把多余的复杂性去掉； – 灵活——保持开放，应对变化。 – Kent Beck “随着年龄的增长，我逐渐意识到编程不仅 仅是让程序运行而已；编程是创造一个易于 理解的，可以维护的，高效的作品” --Google首席java架构师 Joshua Bloch9Biblioteka 什么是好的代码?10
什么是好的代码?
Good code is not bad code
•22中经典代码坏味道--《重构》
– /weiqubo/article/details/7491048
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Duplicated Code(重复的代码) Long Method(过长函数) Large Class(过大类) Long Parameter List(过长参数列) Divergent Change(发散式变化) Shotgun Surgery(霰弹式修改) Feature Envy(依恋情结) Data Clumps(数据泥团) Primitive Obsession(基本型别偏执) Switch Statements(switch惊悚现身) Parallel Inheritance Hierarchies(平等继承体系) Lazy Class(冗赘类) Speculative Generality(夸夸其谈未来性) Temporary Field(令人迷惑的暂时值域) Message Chains(过度耦合的消息链) Middle Man(中间转手人) Inappropriate Intimacy(狎昵关系) Alternative Classes with Different Interfaces(异曲同工的类) Incomplete Library Class(不完美的程序库类) Data Class(纯稚的数据类) Refused Bequest(被拒绝的遗赠) Comments(过多的注释)
5
破窗效应(Broken windows theory )
•亡羊补牢 •千里之堤,毁于蚁穴
6
技术债务(Technical Debt ) 出来混，迟早要还的"
7
xx的代码
8
好代码的重要性
内在质量和外在质量-《代码大全》 管理者有在阅读代码吗 过分关注模型设计 设计与施工分离害了软件工程 代码成了短板-木桶原理 代码会变烂-破窗效应
技术债务类似于金融债务，它也会产生利息， 这里的利息其实就是指由于鲁莽的设计决策 导致需要在未来的开发中付出更多努力的后 果。 --Martin Fowler
13
代码整洁之道
编程态度 （价值观）
编程技艺
编程习惯
14
为什么要使用函数?
15
创建子程序/函数的理由
•减低复杂度 •职责单一 •封装变化 •引入中间的易懂的抽象 •代码复用 •简化复杂的布尔判断 •支持子类化 •转接 适配 •隐藏顺序 •隐藏全局数据
相关标准
• 格式标准 • 命名 • 类/函数长度 • 注释量 • 重复度 • 条件表达式 • 圈复杂度 • ………….
持续集成
代码评审
•交叉评审:项目组成员2~3人进行互相评审(一般2人同 时评审) •代码走查:10人左右,最好同一team,走查代码 •小组评审:10人左右,最好同一team,熟悉业务,学习设计 – 专人负责,定期评审(每周1~2次,每次2小时左右,一 个人代码3~5类) – 提前和代码编写人员沟通,并且指出坏味道 – 进行部分重构,到时演示重构过程. •专家评审:公司专业组织,评审.(抽查评审) •质量部门评审:检查过程是否按照规范,执行相关步骤
16
函数优化
•函数设计三原则
–单一抽象层次SLAP –函数第一原则，短小短小再短小 –单一职责和内聚性
•减少嵌套 •函数的组织，分离关注度 •开闭原则，查询与赋值分离 •设计模式
17
复杂表达式
•引入解释性变量 •封装函数 •分解条件 •表驱动 •尽量不用非
18
软件可变性
•Changeability指的是实现特定修改的难易程度 •包括三个方面：
20
我是程序设计师,我会遵守
21
推荐资料
•网易公开课：斯坦福编程方法学 •推荐书籍： •每个专业软件开发人员必须精通的事项 – /lovelion/article/details/8517 215 •设计模式六大原则 – /sjms/201211023.asp
创建子程序函数的理由16?减低复杂度?职责单一?封装变化?引入中间的易懂的抽象?代码复用?简化复杂的布尔判断?支持子类化?转接适配?隐藏顺序?隐藏全局数据函数优化?函数设计三原则单一抽象层次slap函数第一原则短小短小再短小单一职责和内聚性?减少嵌套?函数的组织分离关注度?开闭原则查询与赋值分离?设计模式17复杂表达式?引入解释性变量?封装函数?分解条件?表驱动?尽量不用非18软件可变性?changeability指的是实现特定修改的难易程度?包括三个方面