Skip to content

Latest commit

 

History

History
86 lines (63 loc) · 4.84 KB

designCodeClean.md

File metadata and controls

86 lines (63 loc) · 4.84 KB

一段代码的优化之路

整体流程

如何发现代码质量问题? common
1.代码是不是容易读?编码规范遵守没?是否和团队的规范一致 
2.如果是工具类那么它是否可以服用?能否用已有的类库?
3.代码是否可扩展?如果添加新的功能,代码是否能实现吗?
4.模块是否清晰,类是否放在了它该放在的位置?
5.是否遵循经典的设计原则和思想?代码是否高内聚低耦合?是否过度设计?
6.代码是否容易单元测试? 是否覆盖正常异常情况?
7.是否参数校验完全?

有一些特殊的?
业务功能是否达到预期?全部的异常情况是否处理了?
日志打印的怎么样?是否容易发现问题
代码是否存在并发,以及多线程安全问题?
性能是否有优化的空间?是否有导致OOM的问题?
接口是否易用?如果是分布式是否幂等以及事务控制的是否完全?
    
let's me check !!!!!!!! 对照这个第一个版本的代码

1.代码是不是容易读?编码规范遵守没?是否和团队的规范一致 
代码不容易度这个很容易看出来,代码行数不多我都看了那么久,
一代码是没有注释的生成算法比较难懂
二代码里面有很多的魔法数字影响可读性
三三个ifelse 比较垃圾 需要去掉重复代码

2.如果是工具类那么它是否可以复用?能否用已有的类库?
可以复用,例如雪花算法一类的也都可以

3.代码是否可扩展?如果添加新的功能,代码是否能实现吗?
扩展性差,IdGenerator 设计成了实现类而非接口,调用者直接依赖实现而非接口,违法了基于接口而非实现编程
即使这么写其实也没问题,设计类在这个环境下是没关系的,项目小,迭代快 如果哪天id的生成算法变了我们就直接修改实现类的代码就可以了!,
但是如果项目中同时存在了俩种Id生成算法也就是要同时存在俩个IdGenerator生成算法,如果我们要给更多的框架使用,
需要灵活的使用那么我们就需要将IdGenerator定义为接口,并且为不同的算法定义不用的类

4.模块是否清晰,类是否放在了它该放在的位置?
这个类比较简单所以不涉及模块划分,大部分都知道给他放在一个合适的位置,也没有代码结构问题

5.是否遵循经典的设计原则和思想?代码是否高内聚低耦合?是否过度设计?
不存在设计原则的问题,也没有过度的设计和使用

6.代码是否容易单元测试? 是否覆盖正常异常情况?
本身呢这个类是很容易做测试的,但是因为定义的是静态函数所有会影响使用该函数的代码的可测试性
代码也没有也测试类,需要在之后补充上

7.是否参数校验完全?
参数校验异常他选择了直接抛出

有一些特殊的?

业务功能是否达到预期?全部的异常情况是否处理了?
功能达到预期 可以生成一些不重复的id但是不能保证绝对不重复 如果hostName 取不到只打印了一个日志并没有处理完全 可以往上抛异常?可以默认值? 等等

日志打印的怎么样?是否容易发现问题
打印的还不错

代码是否存在并发,以及多线程安全问题?
存在 需要优化算法

性能是否有优化的空间?是否有导致OOM的问题?
性能方面足够应对,但是每次获取生成的id都需要去一次主机的host比较耗时所以可以考虑优化一下 oom不至于!

接口是否易用?如果是分布式是否幂等以及事务控制的是否完全?
不涉及

how to 优化?

整体流程

提高可读性 提高可测试性 添加注释
1.提高可读
1.命名规范一下 hostName要能重复使用 将它单独抽离出来 getLastFieldOfHostName 
2.删除代码中的魔法数字,比如57,90,97,122
3.将生成随机数的代码从整体剥离出来 generateRnadomAlphameric();
4.对IdGenerator 类重命名 并且抽出对应的接口

二提高代码可测试性
RandomIdGeneratorTest

三添加注释RandomIdGeneratorTestRandomIdGeneratorTest
RandomIdGenerator

主要就是写清楚: 做什么、为什么、怎么做、怎么用,对一些边界条件、特殊情况进行说明,以及对函数输入、输出、异常进行说明
**** 最后 如果获取主机为null 格式变为null-时间戳-随机数 -- 需要校验还是直接给你一个默认值报警***