序文
一般に、プロジェクトが2年以上存在する場合、コードは肥大化し、保守が困難になります。人事異動があり、新しいメンバーが参加する場合、直面する可能性のある最初の問題は、古いコードに新しい要件を追加する方法です。
私は前に仕事に加わり、古いプロジェクトを引き継ぎました。私の内部活動は次のようになります。
- 新しい機能の追加は古い機能に影響しますか？
- 工事期間が非常に厳しいのですが、機能設計をする時間はまだありますか？コードを直接始めたいですか？
- 新しく追加された機能は既存の機能と非常によく似ていますが、一般の人に言及するのですか、それとも変更のコピーをすぐ下に貼り付けるのですか？公開されている場合、元の機能をテストする必要がありますか？
- 緊急のオンラインバグがありますが、コードは初めて見たものです。今日修正して起動する必要があります。時間が厳しすぎる場合はどうすればよいですか？
- ビジネスロジックが複雑すぎて、反復が頻繁に発生します。コードを確認する時間はありますか？
- 古い機能はなじみがなく、新しい要件に合わせて元のロジックを変更する必要がありますが、ロジックは非常に複雑で、相互作用が多く、UIの実装が簡単ではありません。合理的にスケジュールするにはどうすればよいですか？
ドラマのように見えますが、すべての文章が真実です。古いプロジェクトを引き継ぐ際に遭遇するこれらの質問は、より頻繁に発生するだけでなく、開発の効率と品質にも大きく影響します。
武道の謎「18ドラゴン鎮圧椰子」については研究していませんが、これまでに学んだことを使って「古いコードの魔法」をまとめました。
機能的な回避策
古いページに新しい関数を追加しても、必ずしも元の関数に影響するわけではありません。したがって、開発前に関数を分類すると、「少ないリソースでより多くのことを実行できる」という効果があります。
機能の分離
追加する必要のあるファンクションポイントは、単一のオプションまたはドロップダウンボックスのみである場合があります。現時点では、コンポーネントをカプセル化する必要はありません。しかし、結局のところ、それは古いページに追加され、既存の機能に影響を与えないだけでなく、後で機能拡張も考慮します。
私は通常、機能の分離を行います。JSXの柔軟な書き込み方法のおかげで、コードセグメントをカプセル化するのは非常に便利です。比較的独立した機能について言うことはあまりありませんが、この場合、機能の分離は非常に簡単です。主に依存関係のある機能、それらを分離する方法は？
実際、機能の分離には、少し分離した考え方もあります。関数は依存していますが、コードを一緒に記述する必要はありません。
たとえば、製品の注文の場合、すべての製品タイプの注文が注文管理下にあります。製品Aの製品マネージャーは、製品Aの注文がキャンセルされたときに、2番目の確認プロンプトを表示する必要があると述べましたが、製品Bにはこの要件はありません。
我把是否进行二次确认弹窗的逻辑放在了弹窗外侧的列表操作上。撤单弹窗里面中直接对二次弹窗的处理。这样一来，撤单弹窗中的代码不用关心哪条业务线需要进行二次确认操作。外侧的撤单按钮不需要关心撤单弹窗里面是怎么操作的，只需要把控制二次确认弹窗的变量reconfirmFlag（是否二次确认布尔值）传入弹窗即可。
这样，未来如果再加其他的产品类型，只需求维护列表撤单操作代码里面的条件判断即可。
列表撤单操作
record.reconfirmFlag = false;
// =>true: 帽子产品需要二次确认弹窗
if (record.type === 'hat') {
record.reconfirmFlag = true;
}
撤单弹窗确定操作
/**
* 提交操作
* @param {Object} value 接口入参
* @return {void} 无
*/
const handleSubmit = value => {
let { data } = props;
if (data.reconfirmFlag) {
// 二次确认提示
} else {
// 提交操作
}
};
相似功能的提炼
新增的功能和现有的功能非常相似，也是在开发中经常遇到的情况。可能习惯性的或者为了求稳直接把老代码复制一份，修改修改完事。
看似又快又稳的操作，会导致代码变得越来越冗余，老代码变得越来越难维护。
怎么提炼？
相似功能主要有两点，同和异。相同部分是需要提炼的内容。对于差异的部分，我之前习惯用条件判断，现在习惯用枚举的方式。
不同产品分类展示产品信息
/**
* 产品介绍
* @param {string} type 产品分类
*/
const goodContent = type => {
const good = {
hat: {
title: '帽子',
name: '帽子A',
color: '黑色',
},
shoses: {
title: '鞋子',
name: '鞋子B',
color: '白色',
},
};
const goodItem = good[type];
return (
<div>
<div>{goodItem.title}</div>
<div>
<div>产品名称：{goodItem.name}</div>
<div>产品颜色：{goodItem.color}</div>
</div>
</div>
);
};
return (
<div>
{goodContent('hat')}
{goodContent('shoses')}
</div>
);
不同类型图片展示和编辑
/**
* 图片展示
* @param {Array} imgList 图片列表
* @return {void} 无
*/
const colImgContent = imgList => {
return (
<>
{imgList.length != 0 &&
imgList.map((img, index) => (
<Col span={4} key={index}>
<img className='img-block' src={img} />
</Col>
))}
</>
);
};
/**
* 图片展示
* @param {string} type 图片分类
*/
const imgContent = type => {
const imgObj = {
hat: {
title: '帽子产品展示',
imgList: [],
},
shoses: {
title: '鞋子产品展示',
imgList: [],
},
};
const item = imgObj[type];
return (
<div className='mb10'>
{item.title}：
<Button type='link' onClick={() => uploadImgs(item)}>
编辑
</Button>
<Row gutter={(12, 12)}>{colImgContent(item.imgList)}</Row>
</div>
);
};
return (
<div>
{goodContent('hat')}
{goodContent('shoses')}
</div>
);
老功能要不要测？
当然，测试是肯定要测的。不过提测的时间点可能会因情况而异。
我一般在需求设计阶段就会把需要额外测试的地方标注出来。但是有些需求任务量小不需要设计评审，这种情况下如果要增加额外的测试功能点，需要提前跟测试的同事沟通，一般不是翻天覆地的修改，测试的同事是很好沟通的。如果改动影响范围太大，测试的同事要做风险评估之后，才能确定是否可以进行代码改造。
注：可能每个公司的工作流程不一样，请大家参考公司的实际流程进行提测要求和提测操作。
精准定位
线上的紧急bug、临时上线的紧急需求等，即考验开发者的抗压能力，又考验自身的技术能力。有些技术难题，确实需要过硬的技术功底。但是有些问题，找准问题的关键点，其实不难解决。
不是逗闷子，先来看几个例子。
无法唤起的收银台
前情提要
同事离职之后，叶一一暂时接手了同事负责的工作，还没有完全熟悉那部分业务。这天，叶一一拎着早餐来上班，产品经理过来说一个活动的收银台无法唤起了，让叶一一帮忙看一下。
第一次知道这个活动的叶一一是这样做的
虽然叶一一对这个活动非常陌生，好在所有的活动功能都在项目的activity目录下。找到对应的页面，叶一一没有急吼吼的去熟悉业务，她在做其他业务线购买流程时很清楚一点，进行提交操作之后才会唤起支付收银台，所以叶一一先找到提交按钮，然后再去找唤起收银台的代码，发现这个活动的收银台是跳转第三方的，而跳转第三方url中带有test字符的域名，叶一一就知晓了问题所在。
果然不出所料
叶一一问产品，跳转第三方收银台的链接，测试环境和正式环境的分别是什么。拿到链接之后，果然测试环境带"test"线上不带。叶一一加上环境判断区分不同环境的跳转链接，再上线之后，线上就能正常跳转收银台了。
后续
叶一一后来熟悉这个活动功能的时候发现，活动流程还挺长的，到达购买页面之前至少有5、6个步骤。所以，如果叶一一没有精准定位问题，到达购买页面还得费点功夫。
// 区分线上和测试环境的地址
let prodEnv = env === 'production'
let urlPrefix = prodEnv ? 'https://api' : 'https://testapi';
const url = `${urlPrefix}.com`;
测试通过之后的线上报错
前情提要
叶一一刚接手了从别的组并过来的项目，还没来得及看代码，就来活了，有大概10个页面需要改动。叶一一看不是改文案就是在原来的基础上新增模块，就愉快的定好排期开始干活。
测试通过
很顺利的开发完功能，自测没有什么问题，叶一一就提测了。测试过程也很顺利，上线日，代码早就准备好，就等晚上上线了。
线上验收
线上验收时，测试的小伙伴发现有个接口报错了，后端的同事说这是一个老接口没有做过调整。叶一一找到出现问题的接口，发现是一个很简单的获取数据的接口，都不需要入参。怎么会有问题呢，测试环境明明没有问题。
「全组的等待」+「就差这一个问题就验收通过」的双重压力并没有让叶一一慌乱。叶一一遇到过多次玄妙问题，只要找准问题关键，不难解决。
正式环境和测试环境唯一的区别就是接口加密，会不会加密的接口需要什么特殊处理？叶一一本地运行加密命令，果然接口报错。叶一一又对比了其他接口，唯一区别就是这个接口没有入参。于是叶一一尝试在入参传了一个空对象，果然接口成功并返回数据。叶一一让后端帮忙看加密的逻辑，确实有特殊的逻辑处理。
后续
后来叶一一发现其他项目没有这个问题，是因为在axios封装时做了特殊处理，新接手的项目没有进行处理。
// 处理过
config.params = JSON.stringify(params);
// 未做处理
config.params = params;
小结
有些问题，在特殊场景才会出现，这个时候通过对比特殊场景和常规场景的异同，找到不同点，能够帮助快速解决问题。
业务变通
熟悉业务
与其担心不熟悉业务，不好改需求或者评估开发排期，不如抽时间熟悉业务。业务熟悉起来也可以间接的提升开发速度和开发质量。
业务线太多怎么办？
我个人是「好记性不如烂笔头」这一派的。我无法一次记住全部的业务功能，那就写写文档，将功能梳理出来。
如果业务线多，那就一条一条的捋。切记「贪多嚼不烂」，以及避免「迷路蜜蜂」的状态。
单个业务如何梳理？
不同的业务，梳理的侧重点也会有所不同。
- 流程较长的业务，需要捋顺整个流程。可以通过绘制流程图的方式，辅助理解和记忆。
- 交互复杂的业务，需要新定边框，再细化交互设计。交互是比较分散的，但是类型比较确定，弹层是弹层，下拉项是下拉项。整体的交互风格先定好，可以减少后期的修改。
- 内部逻辑复杂的业务，需要拆分层级。先拆成最小颗粒度，再做功能组合，有点像搭积木，先把形状分类好，再搭结构，最终完成「图纸」上的模样。
- 偏活动类的业务，梳理文档中，最好列出来活动入口、参与规则（可能会影响前端的功能）、参与记录的查看方式等。
已整理业务文档数量
| 类型 | 文档数量/个 |
|---|---|
| 产品线文档 | 12 |
| 理赔组业务文档 | 7 |
抽离业务组件
先绘制出全部业务模块，分门别类。然后横向对比业务功能，思索今后的发展，确定哪些功能是可以抽离业务组件的。
抽离的本意，一方面提升代码的复用率，不必重复开发；另一方面，可以将复杂功能拆解，便于后续的快速迭代。
抽离的好处，功能写的又快又好，一次开发，造福未来。
我之前写过一篇关于业务组件的思考，这里不展开说了，指路☞ 【工作小记】关于业务组件的思考 。
思维变通
设计文档
我的设计文档主要包括三部分内容，开发前准备、开发排期、需求拆分和重点功能设计。
开发前准备
准备的内容主要是功能开发之外的事情。
比如小程序开发是否需要新增业务域名，新增的项目是否需要运维的同事帮忙配置域名，公众号新增页面上线之后是否需要提供入口链接等。这些可以再设计文档中进行记录，避免遗忘。
开发排期
我的开发排期中包含每一项开发需要的具体时间，以页面为维度，以小时为最小的时间单位，然后汇总成天数。实际的开发周期和联调周期，还需要结合手上有没有其他并行的需求和后端同事的开发周期。
需求拆分和重点功能设计
我会把所有的需求罗列出来，避免漏掉哪个。但是功能设计一般只会做重点功能，或者一些组件封装的设计。
重点功能设计主要是处理方案和重点功能代码块，如果流程复杂的会附上流程图；如果状态值较多的项，附上枚举值对应表格。
抽丝剥茧
并不是所有的功能是复杂的，把功能抽离到最小功能，肯定有是简单的部分，而复杂的内容只占其中一角。
比如一个列表页，搜索项和列表展示比较简单，删除操作页很简单。但是新增的表单很复杂。
如果卡在复杂的功能处，不妨先完成简单的部分。如果经常卡在复杂的功能上，就要自我反思一下了，平时有没有做功能整理和技术提升，来帮助自己更好更快的开发复杂功能。
排期变通
正向排期总是失误，不妨试试反问式排期方法。
- 为什么只是在原来功能中加了一个小需求，但是写的排期却这么长？它难在兼容老功能还是新增的功能？
- 为什么修改的项这么多，但是写的排期时间却这么短？复杂程度是不是真的不高，不要被想当然坑了自己？
- 别的页面需要的时间都很短，为什么唯独这个页面需要这么长的时间？它的复杂点到底在哪？
- 为什么联调的时间反而比开发的时间长？是我联调时间写长了？还是开发时间写短了？还是联调接口太多，参数太复杂？
总结
对于老代码的改动，确实耗时又费心神。所以我有时候会在我的设计文档中，写一些鼓励自己的俏皮话。一定要好玩一点不要太中规中矩，才能逗笑自己的同时，激发干活的热情。
凡事留一线，代码好扩展。
功能设计好，bug见得少。
今天努力捋顺的需求，都是日后宝贵的财富。
ナゲッツテクノロジーコミュニティのクリエイター署名プログラムの募集に参加しています。リンクをクリックして登録し、送信してください。