迁移学习 保持参数不变_迁移到打字稿，使其保持平稳

迁移学习 保持参数不变

In the process of transitioning two mature frontend codebases (totalling ~5k files / 300k lines) from Javascript to Typescript, I learned a bit about the process that might be helpful to anyone considering this change in their stack. Much of this advice is not really specific to Typescript, and could possibly be generalized to any language or framework migration — but I’ll stick to what I know.

在将两个成熟的前端代码库(总共约5k文件/ 300k行)从Javascript转换为Typescript的过程中，我学到了一些有关该过程的信息，该过程可能对考虑堆栈中此更改的任何人有所帮助。 这些建议中的大部分并不是真正针对Typescript的，并且可能会推广到任何语言或框架的移植-但我会坚持我所知道的。

1. Write all new code in Typescript — sometimes

1.用Typescript编写所有新代码-有时

Don’t create extra work for your team down the road by pushing more code to be migrated later — as soon as Typescript has been introduced into your stack, every pull request going forward should be written in TS. But how strict should this be? It’s easy enough to write new files and components in TS, but what about changes to existing files? If a pull request changes just one line in a file, should the whole file be converted?

不要通过在以后推送更多代码来为您的团队增加额外的工作，因为一旦Typescript被引入到您的堆栈中，以后的所有拉取请求都应该用TS编写。 但是，这应该有多严格？ 在TS中编写新文件和组件很容易，但是对现有文件的更改又如何呢？ 如果拉取请求仅更改文件中的一行，是否应该转换整个文件？

Requiring devs to migrate every changed file can be a morale and productivity killer. Even the smallest bug fixes become chores, and PRs for new features are impossible to review as the diff often interprets migrated files as being new. On the other hand, if the migration isn’t required, the work might never get done. This is particularly true for older files that aren’t edited often. Find the balance that makes sense for your team and keeps the migration moving forward.

要求开发人员迁移每个更改的文件可能会打击士气和生产力。 即使最小的错误修复也变得很繁琐，而且由于差异通常会将迁移的文件解释为是新文件，因此无法审查新功能的PR。 另一方面，如果不需要迁移，则可能永远无法完成工作。 对于不经常编辑的旧文件尤其如此。 找到对您的团队有意义的平衡，并保持迁移的进行。

2. Convert common files and generic components first

2.首先转换通用文件和通用组件

You’ll get the most immediate benefit from Typescript’s features by targeting the files most likely to be imported in any new feature work. If these shared components aren’t converted, you’re building up tech debt in all of your new TS files. Get ahead of this and enjoy the autocomplete and instant errors on all your new files.

通过定位最有可能在任何新功能作品中导入的文件，您将从Typescript的功能中获得最直接的收益。 如果未共享这些共享组件，那么您将在所有新的TS文件中积累技术债务。 领先于此，享受所有新文件的自动完成和即时错误。

Use the most accurate type available for all the properties of the API on these core components. It can be challenging to find the exact type for functions, callbacks, and events (especially for React events, DOM properties, or third-party dependencies), but it will save you trouble downstream in your consumers. Going slowly to get the core components right will save you time overall.

对于这些核心组件上的API的所有属性，请使用最准确的类型。 找到函数，回调和事件的确切类型(尤其是针对React事件，DOM属性或第三方依赖项)的确切类型可能是具有挑战性的，但是它将为您的使用者避免下游麻烦。 慢慢解决核心组件问题将为您节省总体时间。

3. Communicate with your team about upcoming migrations

3.与您的团队就即将进行的迁移进行沟通

Migrations can sometimes create huge diffs that lead to nightmarish merge conflicts if multiple devs are working in the same file. Don’t set yourself up for pointless hours of frustrating and buggy conflict resolutions. Check in with your team before starting a migration. If there’s significant activity in that area of the code, consider postponing the work or basing your branch from theirs.

如果多个开发人员正在同一个文件中进行迁移，迁移有时会造成巨大的差异，从而导致噩梦般的合并冲突。 不要在无聊的，无聊的冲突解决上花费大量时间。 开始迁移之前，请与您的团队联系。 如果该代码领域有大量活动，请考虑推迟工作或将分支机构置于其基础之上。

4. Resist the urge to refactor

4.抵制重构的冲动

When migrating any large codebase, you’ll inevitably find yourself opening ancient files with terrible debt. Gross, look at all these deprecated patterns and inefficiencies. Oh, you could totally write this in a third of the lines. No one’s using this function any more, right? Snip-snip.

迁移任何大型代码库时，您不可避免地会发现自己负债累累地打开了古老的文件。 毛，看看所有这些过时的模式和低效率。 哦，您完全可以在三分之一行中写下它。 没人再使用此功能，对吗？ 剪断

It’s hubris. Don’t do it. You’re going to create regressions. Be good to yourself and your team. Don’t stress QA out.

这是傲慢自大。 不要这样 您将要创建回归。 对自己和您的团队好。 不要强调质量检查。

5. Avoid maintaining parallel versions of the same component

5.避免维护同一组件的并行版本

Sometimes, migrating a complex or highly-used component is just too fraught to risk an in-place conversion — in such situations, the only choice might be to duplicate, convert, and gradually swap out the old for the new throughout your codebase. But as long as both versions exist, there will be confusion about which one to use; the old one will get imported by habit or copy-paste; bug fixes and enhancements will need to be applied to both; behavior may even drift over time.

有时，迁移复杂或使用率很高的组件实在太麻烦了，以至于无法进行就地转换-在这种情况下，唯一的选择可能是在整个代码库中复制，转换并逐渐将旧的替换为新的。 但是，只要两个版本都存在，就会混淆使用哪个版本。 旧的将通过习惯或复制粘贴导入； 错误修复和增强将需要同时应用于两者； 行为甚至可能随时间漂移。

Minimize the amount of time spent in this situation — when adding a duplicate TS component, prioritize this area of migration. Name your files and components clearly to avoid confusion when importing.

最小化在这种情况下花费的时间-添加重复的TS组件时，请优先考虑此迁移区域。 清楚命名文件和组件，以免在导入时造成混淆。

6. Account for migrations in estimations and planning

6.在估算和计划中考虑迁移

When providing time or point estimates for future work, add another 20% if you plan on migrating the code first. Plan out your migrations; if you know that major work is upcoming in one area, get the migration done early. Don’t leave it as an invisible or unexpected cost.

在为将来的工作提供时间或点估计时，如果您计划首先迁移代码，请再增加20％。 计划您的迁移； 如果您知道某个领域即将进行重大工作，请尽早完成迁移。 不要将其视为无形或意外的代价。

7. Leave a comment whenever you use ts-ignore or any

7.每当您使用 ts-ignore 或 any 时，请发表评论

Some of your third-party dependencies are going to give you incorrect type definitions that leave you scratching your head for days. An obscure corner case with generic tuples will send you down a Stack Overflow wormhole for 5 hours. The greatest good is to keep moving forward and leave good comments whenever you’re forced into a hack.

您的某些第三方依赖项将为您提供错误的类型定义，从而使您花了好几天的时间。 带有通用元组的不起眼的角落保护套将使您在Stack Overflow虫洞中停留5小时。 最大的好处是，当您被迫遭受黑客入侵时，请保持前进并留下良好的评论。

8. Don’t let it linger

8.不要让它流连忘返

One of the possible migration routes for Typescript is to progressively increase its strictness; turning off these rules can be helpful while getting started, but delaying this for long will hold your team back from the full benefits of the language. It can be a high cost initially as you get the necessary dependencies migrated so even a single component can be fully typed, but it’s better than facing a massive diff on the horizon once you do enable it.

Typescript可能的迁移途径之一是逐渐提高其严格性； 入门时，关闭这些规则可能会有所帮助，但长时间延迟将使您的团队无法充分利用该语言的全部好处。 最初，当迁移必要的依赖项时可能会付出很高的代价，因此即使是单个组件也可以完全键入，但是比启用它之后面对巨大的差异要好。

There will be boom and bust periods in the speed of change, but mid-migration tech debt is exhausting to deal with. You can never remember which component has been converted already or not. You still can’t trust the IDE to catch some of the biggest mistakes in your code. Why did we even start this stupid transition in the first place?

变化的速度将有繁荣和萧条的时期，但是中迁移的技术债务正在竭尽所能。 您永远不会记住哪个组件已经转换。 您仍然不能相信IDE会捕获代码中的一些最大错误。 为什么我们首先要开始这种愚蠢的过渡？

But the virtues of a strongly typed language grow exponentially as more of the codebase is converted. The first time you refactor a core component and the compiler immediately tells you down to the line and column where the fixes are needed, it’s all worth it. Most other languages have had this experience for decades, of course, but not Javascript.

但是，随着更多代码库的转换，强类型语言的优点呈指数增长。 第一次重构核心组件时，编译器会立即告诉您需要修复的地方，这是值得的。 当然，大多数其他语言都具有这种经验数十年，但Java语言却没有。

Good luck! It’s a lot of work, but it will eventually pay off.

祝好运！ 这是很多工作，但最终会取得回报。

翻译自: https://medium.com/swlh/migrating-to-typescript-keeping-it-smooth-steady-f4a9b359f575

迁移学习 保持参数不变