我在大厂做 CR——再谈如何优雅修改代码
书接上回为什么需要依赖注入再做下扩展
上文谈到:“基于抽象接口编程确实是最佳实践:把易于变动的功能点通过定义抽象接口的形式暴露出来,不同的实现做到隔离和扩展,这体现了开闭原则”
public class Foo {
private Bar bar ;
@Inject
public Foo(Bar bar) {
this.bar = bar;
}
public String doSomething(int key) {
//Bar#getResult 体验了代码的复杂性,通过注入不同的 Bar 实现对象,做到功能点的隔离和扩展
return bar.getResult(key);
}
}
但在真实项目里,往往是多人协作一起开发,一些历史原因导致某些代码片段的实现往往“千奇百怪”,既不能很好的单侧覆盖,同时也充斥着违反了开闭原则的“代码坏味道”;
而此时的你,作为“被选中的人”,需要对其功能迭代;
或许经过你的评估后,可以去大刀阔斧的架构演进,这是点赞的;
但有时也要全局 ROI 去评估大刀阔斧重构收益是否足够大,有时候我们只能妥协(trade-off
)。即:如何在紧张的交付周期内做到比较好的重构,不让代码继续腐化;
所以这次继续介绍两种修改代码的艺术:方法新增和方法覆盖
策略 1:方法新增
通过新增方法来隔离旧逻辑,即:在旧方法里横切“缝隙”,注入新的业务逻辑被调用;
拿之前的 Case 举例,一个历史老方法,需要对返回的数据集合过滤掉空对象:
public class Foo {
private Bar bar;
public Foo() {
bar = new Bar();
}
public List<Data> doSomething(int key) {
//依赖三方服务,RPC 调用结果集
List<Data> result = bar.getResult(key);
//过滤掉空对象
return result.stream().filter(Objects::nonNull).collect(Collectors.toList());
}
}
此处逻辑很简单,使用了Java Lambda
表达式做了过滤,但这样的写法无疑雪上加霜:确实原先方法已经很 Low 了,也无法单侧。本次只是在最后加了一段简单的逻辑。已经驾轻就熟了,可能不少人都会这样搞;
但作为好的程序员,眼前现状确实我们只能妥协,但后续的每一行代码,需要做到保质保量,努力做到不影响原有业务逻辑下做到可测试;
“方法新增”:通过新增方法 getDataIfNotNull
来隔离旧逻辑:
public List<Data> doSomething(int key) {
//依赖三方服务,RPC 调用结果集
List<Data> result = bar.getResult(key);
return getDataIfNotNull(result);
}
如下 getDataIfNotNull
作为新增方法,很容易对其进行独立测试,同时原有的方法 doSomething
也没有继续腐化
public List<Data> getDataIfNotNull(List<Data> result) {
return result.stream().filter(Objects::nonNull).collect(Collectors.toList());
}
可以看到优点很明显:新老代码清晰隔离;当然为了更加职责分明,使用新增类隔离
会更好;
策略 2:方法覆盖
将待修改的方法重命名,并创建一个新方法和原方法名和签名一致,同时在新方法中调用重命名后的原方法;
假设有新需求:针对 doSomething
方法做一个消息通知操作,那么“方法覆盖”即:将原方法 doSomething
重命名为 doSomethingAndFilterData
,再创建一个与原方法同名的新方法 doSomething
,最后在新方法中调用更名后的原方法:
//将原方法 doSomething 重命名为 doSomethingAndFilterData
public List<Data> doSomethingAndFilterData(int key) {
//依赖三方服务,RPC 调用结果集
List<Data> result = bar.getResult(key);
return getDataIfNotNull(result);
}
//创建一个与原方法同名的新方法 doSomething
public List<Data> doSomething(int key) {
//调用旧方法
List<Data> data = this.doSomethingAndFilterData(key);
//调用新方法
doNotifyMsg(data);
return data;
}
//新的扩展方法符合隔离扩展,不影响旧方法,也支持单侧覆盖
public void doNotifyMsg(List<Data> data){
//
}
方法覆盖的另一种写法:通常是再定义一个新的方法,然后在新的方法依次调用新老业务逻辑;
一般在架构演进的时候,用于切流新老逻辑;例如:基于客户端版本,大于 3.10.x
的客户端切流使用新的逻辑——我们创建一个新的方法调用新旧两个方法。
//老的历史代码,不做改造
public List<Data> doSomething(int key) {
//依赖三方服务,RPC 调用结果集
List<Data> result = bar.getResult(key);
List<Data> data = getDataIfNotNull(result);
return data;
}
//新创建一个方法,聚合调用新老逻辑
public List<Data> doSomethingWithNotifyMsg(int key) {
List<Data> data = this.doSomething(key);
//调用新方法
doNotifyMsg(data);
return data;
}
//新的扩展方法符合隔离扩展,不影响旧方法,也支持单侧覆盖
public void doNotifyMsg(List<Data> data){
//
}
这样的好处是显然易见的,不针对旧方法做修改,同时在更高维度的“上层”切流:保证新功能正常迭代演进,老功能维持不变
boolean enableFunc=getClientVersion()>DEFAULT_CLIENT_VERSION;
if (enableFunc){
return doSomethingWithNotifyMsg();
} else {
return doSomething();
}
可以看到“方法覆盖”不管用何总方式实现,它不会在当前旧方法里增加逻辑,而是通过使用新方法作为入口,这样避免新老逻辑耦合在一起;
“方法覆盖”可以再进阶一步,使用独立的类来隔离,也就是装饰者模式。通常情况下原有的类已经非常复杂了,已经不想在它上做功能迭代了,考虑使用装饰者来解耦:
class DecoratedFoo extends Foo{
private Foo foo;
public DecoratedFoo(Foo foo){
}
@Override
public List<Data> doSomething(int key) {
List<Data> data = super.doSomething(key);
notifyMsg();
return data;
}
private void notifyMsg(){
}
}