如何减少项目中的冗余代码
2021 M06 28
前言
随着业务的不断迭代,项目代码会变得越来越多。
如果前期不注意开发规范和代码层次结构规划,到后期项目中就会出现大量的冗余代码,维护困难。
到最后,多是以重构,新建项目重写收尾。
原本,可以更好的。
本周双休,今天我们就来聊一下如何减少项目中的冗余代码。
为什么会出现冗余代码
结合我的经验来看,出现冗余代码的情况包括但不限于以下几个方面:
- 对于公共请求/业务逻辑未做提取
- 能收敛为聚合函数的函数直接提供给外部调用
- 能合并的函数未合并
- 相似结构的复制粘贴
如何解决
核心思想是能合并的合并,能提取的提取。
其实都是建议,这种东西,咬牙也能坚持。
能过就过,不能过还能离咋的?
提取公共请求/业务逻辑
比如对某项数据进行订阅和取消订阅,二者只是动作上的区别,参数是一致的。
不要在每个模块下都写一份订阅和取消订阅的逻辑,提取到全局公共逻辑中
不要写两个处理函数,用动作区分即可(以mobx为例)
// subscribes 为用户订阅数据id集合
// bad case
if(subscribes.includes(row.id)){
store.cancel()
}else{
store.add()
}
// good case
store.subscribe(row.id,subscribes.includes(row.id))
async function subscribe(id,flag){
let url=''
if(flag){
// 取消订阅
url='/api/subscribe/cancel'
}else{
//新增订阅
url='/api/subscribe/add'
}
await axios.post(url,{id})
}
此外,还有一个更典型的场景。登录平台获取用户信息后,为方便其他模块使用,这个信息应该放在全局,而不是每次使用再去发一个请求。
聚合函数的收敛
给定这样一个场景,新建项目并指定负责人后,会同步资源(该项目)到权限系统,并为资源对应的人赋权。
// bad case
// 创建或者更新资源信息
export function addOrUpdate(){}
//赋权
export function addPermission(){}
上述这种写法存在一个弊端,直接提供给外部的话,两个方法都要调用。
事实上,这两个是一体的行为,创建或者更新资源后,紧接着就是赋权。addPermission是addOrUpdate的子函数,直接内部调用就好。这样外部只需要调用聚合后的函数addOrUpdate即可。
// good case
// 创建或者更新资源信息
export function addOrUpdate(){
addPermission();
}
//赋权
function addPermission(){}
能合并的函数进行合并
这个比较好理解,就像上边提到的订阅和取消订阅,只是动作差异,完全可以合并为一个。
此外,类似的还有插入数据和更新数据,这里动作判断标准是是否有id,有的就是更新,没有就是插入。
if(params.id){
service.update(params)
}else{
service.add(params)
}
善用配置表思维
之所以选择复制粘贴,是因为相似结构很多,对于这种情况,配置表+循环则是更优解。
再会
情如风雪无常,
却是一动即殇。
感谢你这么好看还来阅读我的文章,
我是冷月心,下期再见。