实战总结|记一次迭代需求中的微型代码重构
阿里妹导读
本文记录了程序员一次普通的日常需求中的微型重构过程。
需求背景
需求评估
没看到原页面代码之前可能认为这是个很小的需求。页面上组件移动一下位置不就好了嘛。需求很快完成,业务方满意,我们都有美好的明天。看了代码顿觉自己天真。并没想象的这么简单,而且很容易出错。为描述清楚原因,下面使用了字母缩写,大家可不用理解其中的业务含义。
要完成这个需求,要做的应该是这三件事:1. 找到目标位置,2. 找到目标组件,3. 移动。
先分析下现在的页面结构:页面Page包含A和B两个组件,组件A有a1和a2两个子组件,目标位置就在a1和a2之间,目标位置很清晰。问题在B里。要移动的b1部分是在组件B内,但b1不是一个组件,而是一堆在B内部的代码。b1逻辑中出现了2个组件AR和HR,不同条件下可能展示其中之一,或者不展示。且b1依赖了B上下文的10个属性。如果目标b1不是组件,移动复杂度UPUP。
b1部分的代码示意:
...
/** b1部分的代码 */
let hRecord = null;
const hasSupplySuite = hasSupplySuite();
if (type === TypeENUM.REPAIR_CHECK && data && !hasSupplySuite) {
hRecord = (
<ARecord
id={originatorInfo.workNo}
pId={pId}
/>
);
} else if (hasSupplySuite || type > 1) {
hRecord = (
<HRecord
pId={pId}
id={originatorInfo.workNo}
count={currentCount}
name={schema.title}
username={originatorInfo.name}
isLeave={type === TypeEnum.LEAVE}
code={formData.code.value}
/>
);
}
if (!isUserInList() || location.href.indexOf('list') !== -1) {
hRecord = null;
}
...
A和B两个组件的API已经三十多个了,估计是经年累月一个需求接一个需求叠加上去的,如果为本次需求按照惯例要叠加更多API上去,并且需要注意避免遗漏和冲突。
这种方式很不美好,对未来扩展没有任何助益,反而坑越挖越深。重构之心蠢蠢欲动。
当然,面对是否选择重构,是会有不少想法的,例如:
3.重构还可能引起bug,带来不必要的麻烦,我要承担这个风险吗?
这些可能也是老的应用代码年久失修的部分原因。但是:
3.如果不重构,内心会很自责;
重构目的
为时间成本可控,最小化重构范围,需要围绕需求明确本次的目标。
目标:让完成本次需求变得更容易。
这需要做三件事:
3.不改变原有功能。
重构过程
老代码重构,要格外小心。设计好重构步骤,每步一个独立的小改动,做到每一步可测,每一步代码可用,降低bug出现概率。
分析b1部分的代码逻辑,其中引用了两个组件,ARecord和HRecord,简称AR和HR。HR是个独立的组件。AR是写在组件B中。既然b1要封装成组件,首先要将AR独立封装。
1. 使AR组件独立,而不是附属于B内
先将AR的代码从B中迁出,稍加改造,将API进行封装,补上类型定义。使用context表示引用组件宿主的上下文信息,例如可以将埋点页面来源信息放到此对象中。componentProps表示组件数据。这一步相对比较简单。
原代码在B中:
class ARecord extends React.Component {
openARecord = () => {
const openUrl = `${getBaseUrl()}#/list`;
openLink(openUrl);
}
render() {
return (
<div className="content" onClick={this.openARecord}>
...
</div>
);
}
}
// 从AFlow中将ARecord迁移出来稍加改造
// 组件接口定义
interface IARecordProps {
className?: string;
style?: object;
context: IContextModel;
// 本组件的数据
componentProps: {
id: string;
pId: string;
}
}
export default function ARecord(props: IARecordProps) {
const {
className,
style = {},
context = {},
componentProps,
} = props;
const {
utSpace,
} = context;
const {
id,
pId,
} = componentProps;
const openARecord = (id: string, pId: string) => {
const openUrl = `${getBaseUrl()}#/arecordlist`;
openLink(openUrl);
};
return <div className="content"
onClick={() => openARecord(id, pId)}
>
...
</div>;
}
在Page中给B组件增加context属性,在B组件内的原位置,引用新的AR组件,按照AR的API传递数据,测试页面逻辑。测试通过。
3. AR和HR都具备了可移动的条件,开始封装b1组件
这步有点棘手,主要原因是b1代码和B组件耦合太深。依赖的有属性,也有方法。先从大的方面着手,原来用了哪些属性先不动。先定义新组件的对外API,原封不动和原组件对应。因为原代码里没有类型定义,确定原属性是什么类型还是花了一些时间。
顺手补上类型定义。
组件封装时,API设计很重要。我更习惯将容易变化的部分封装,例如将组件的API设计为两个对象,context和componentProps,分别代表宿主上下文和组件数据。宿主使用起来简单清晰,后续如有添加新属性,只需增加数据处理的逻辑即可,不用改模板部分的代码,代码看起来简洁,修改成本也更低。
// b1组件数据模型定义
interface IHRecordSummaryData {
hasSupplySuite: ()=>boolean;
id: string;
pId: string;
type: TypeEnum;
data: {};
count: number;
name: string;
username: string;
code: string;
isUserInList: ()=>boolean;
}
// b1组件数据API定义
interface IHRecordSummaryProps {
className?: string;
style?: object;
context: IContextModel;
// 本组件的数据
componentProps: IHRecordSummaryData;
}
export default function HRecordSummary(props: IHRecordSummaryProps) {
const {
context,
componentProps,
props; =
const {
id,
pId,
componentProps || {}; =
const getComponentNode = (componentProps: IHRecordSummaryData) => {
const {
hasSupplySuite,
id,
pId,
type,
data,
count,
name,
username,
code,
isUserInList,
componentProps || {}; =
const aRecordData = {
id,
pId,
}
if (type === TypeENUM.REPAIR_CHECK && data && !hasSupplySuite) {
return <ARecord
context={context}
componentProps={aRecordData}
/>;
if (hasSupplySuite || type > 1) {
return <HRecord
pId={pId}
id={id}
count={count}
name={name}
username={username}
isLeave={type === TypeEnum.LEAVE}
code={code}
/>
}
if (!isUserInList || location.href.indexOf('list') !== -1) {
return null;
}
};
return <div>
{getComponentNode(componentProps)}
</div>;
}
4. 页面功能测试
在B的原位置引用b1组件,按照组件数据类型定义组装componentProps数据并测试。测试通过。
B封装传给b1的数据:
...
const context = {
utSpace: context?.utSpace,
};
const hRecordSummaryData = {
id: originatorInfo?.workNo,
pId: pId,
hasSupplySuite: hasSupplySuite(),
type: type,
data: data,
count: currentCount,
name: schema?.title,
username: originatorInfo?.name,
code: formData?.code?.value,
isUserInList: isUserInList(),
};
...
return (
...
<HRecordSummary
context={context}
componentProps={hRecordSummaryData}
>
</HRecordSummary>
...
)
5. b1组件纠结一下API设计
搬运的原依赖的属性共10个,由于原10个属性通过10个API从Page传给B,再从B传给b1,封装成一个对象会更方便,未来扩展也只需要增加扩展字段的逻辑,而不需要修改模板部分的代码。是否适合封装成对象,还要看这10个在其他位置是否有使用。通过在B的代码中搜索,10个属性中只有1个是其他逻辑在使用,其余的只在b1中使用。可以先封装。
首先,将B的10个API合并成1个API,类型是对象,共10个属性,在B中取到这1个对象传给b1。
然后,在Page中组装这个对象,传给B,同时删除B原来多余的9个API,记得保留1个其他逻辑在使用的。对B来说,新增1个API,删除了9个,B的API从37个减少到29个,代码也清爽了一些。
6. 页面功能测试
将从Page传到B再传到b1的10个属性改成1个对象并测试。测试通过。
7. b1组件纠结一下类型定义
b1的原属性中传递了2个方法,原样搬过来的。查阅代码,这两个方法并有没和当前上下文有关系,可以改成只传方法的结果的boolean值,传个方法不必要。
8. 页面功能测试
将从Page传到B再传到b1的2个方法改成boolean值并测试。测试通过。
9. b1组件类型定义中data
只给组件设计必要的API,不传冗余的数据。
查阅代码,同样的,其中一个属性data仅在条件判断中用了一下,仅使用其是否存在作为条件,但data本身数据量可不小。实际可以改成boolean值。
10. 页面功能测试
将从Page传到B再传到b1的data改成boolean值并测试。测试通过。
11. 目前,具备了组件快速移动的条件
至此,代码已经具备了,将组件快速移动位置的条件。后面操作起来就容易了。将ApproveHead添加同样的组件数据类型定义,将ApprovePage传给ApproveFlow的数据传给ApproveHead,将组件引用从ApproveFlow改成ApproveHead。需求便完成。
12. 页面功能测试
页面功能回归测试,测试通过。
总结
好的代码总让人赏心悦目,读者思路容易和作者达成一致。每次需求都是一次改善老代码的机会。坚持写让人容易理解、让人容易修改的代码,将重构落入到每次需求迭代中,避免代码日久年深而腐坏。
但需求迭代有周期,不能每次搞得翻天覆地。确定好每次重构的目的,适可而止,既可以尊重业务节奏,又可以进行优化。铢积寸累,日就月将,也会有所改变。
"任何一个傻瓜都能写出计算机可以理解的程序,只有写出人类容易理解的程序才是优秀的程序员。" - Martin Flower
欢迎加入【阿里云开发者公众号】读者群
微信扫码关注该文公众号作者