注意
本次迁移因为涉及到内部的一些信息所以对有些信息做一个别名
- 新平台 A平台
- 旧平台 B平台
- 国际化平台 C平台
背景
因为业务调整,两个平台业务合并，所以B台的模块迁移到A平台。两个平台的目录结构不一样。但是技术栈差不多，都是使用react+redux。
提前准备
提前准备的话其实是先摸清大概要迁移的模块功能，就是读代码，
迁移
-
scss to less 就是把对应的页面文件依赖copy过来，scss to less，其实语法都差不多，所以没什么难点，但是这里就有个麻烦点，就是scss文件太多，如果使用react的同学就知道，因为如果你直接引入样式文件其实是全局的，这里的话造成样式覆盖(css三大特性:继承性、层叠、优先级)，所以项目中我们使用的使用的是 css module,当然也有一些css in js的库，例如 styled-components、emotion。优缺点都有，看实际项目考虑点。其实这里语法转换其实应该是写个脚本，直接批量转换，但我再考虑到批量转换的过程中怕出错，所以没直接使用脚本，人工转换，这里有点弱智，效率不高。
-
依赖整理
接下来就是mock数据(charles)让页面显示，根据对应的页面，看对应的页面文件，然后改文件路径，把对应的依赖提到对应的文件中。这里其实也很愚蠢，一个一个改路径，其实应该批量转换成路径别名。 -
状态管理工具整理 现在再提状态管理，其实有点感觉旧话重提的感觉，这个话题讨论过无数次了，我谈谈自己的感受。算了太忙了，就列出来。
1.redux
2.context
3.hooks + context
... 4. 国际化处理 其实对于国际化方案，我们有C平台，把对应的内容导入平台，然后获取key值，在这里会有对应的环境变量去判断读取哪种国家的文案。
| key | source | usa | ... |
|---|---|---|---|
| juejing | 掘金 | juejing | ... |
import React, { FC } from 'react'
import { get } from 'c';
interface Props {};
const App:FC<Props> = props => {
return <div>{get('juejing')}</div>;
}
之前在其他公司工作的时候,其实那时候做国际化是所有的文案都是后端下发。
遇到的问题
-
业务不了解 先了解需求，对应业务，再看代码，事半功倍。不然接口数据结构突然改动，你会变得很被动，而且还没有原来的接口文档。 重要的事情说一遍: 看代码，了解需求、了解业务。
-
没有让自己有危险意识，以为只是那几个页面，没想到页面越多越多。 本以为是迁移几个页面，就看了几个页面的代码，但最后发现自己太愚蠢了，所以得做到第1点。
-
没有owner意识 沟通，再沟通，有风险提前说，不懂就问。之前我就把一个大需求搞砸了。
-
盲目的迁移 不要只看代码，先了解功能，再了解代码。
-
对于迁移过来的页面没有合理规划 其实事前，应该了解A平台的规范，这样迁移后才能更规划代码。例如eslint规范，例如目录结构等。不然你就等于再造了一堆垃圾。
-
代码看到问题就去优化 ... 之后再补了 包括问题点、定位手段等等。
写在最后
一篇没有任何技术含量的文章，就当我自己的一个记事本。毕业后浑浑噩噩的过了很长时间，因为一些事情而烦恼。例如孤独，以前自己习惯孤独，毕业后害怕孤独，终于在今天提起勇气认真去做事情。 希望无论谁都要认真对待生活。
