Swift 3（即时消息：迁移）

最近有人告诉我要将一个商业项目转换为Swift3。然后它是用Swift 2.0编写的。 希望这些笔记可以帮助某人做同样的事情。

迁移过程中需要完成三个高级步骤

1. 更新第三方依赖关系；
2. 更新您的应用程序项目和内部框架；
3. 更新你的叉子（这是一个痛点，我告诉过你！）。

语言

从第一天开始，我就一直在用Swift写作，但是我对Swift 3没有太多的经验。我发现迁移擅长于学习Swift 3的特定知识，但从一开始就不擅长学习Swift。

关于该语言有很多读物，但我建议您先阅读迁移指南-它具有指向相关文档的链接。

API设计准则

这是Swift [3]开发人员的知名读物。 我要说的是，这些指导方针相当简单并且易于理解。 但是，除非您已经使用Swift 3编写了一段时间，否则您可能会发现它们很难立即掌握。 没关系 如果您今天对如何使您的API更加“灵活”不了解，请保持原样。 在某些功能实施或错误修复期间，您下次可能会想到一个好主意。

第三方依赖性

这是迁移到Swift 3弄脏手后要检查的第一件事。

我想说，您越推迟迁移，就越有可能将所有依赖关系都迁移到Swift 3。 如果您过去不太幸运，选择了一些后来被废弃的库，那么，您可以从项目中删除它，也可以自己复本。

在GitHub上访问每个依赖项的页面，并在各个电子表格中记录有关Swift 3支持的注释，可以使您在该主题上花费一些精力。

Xcode 8 Swift迁移器工具

当您选择迁移时，Xcode会提供一个迁移助手。

不要使用助手的视图来查看和编辑更改。 相反，只需批准所有建议并通过您选择的git UI工具对其进行审核。 为什么？ 好吧，您可以称我为宽松的人，但是当我查看并编辑80％的代码库时，Xcode 8突然崩溃了。 可悲的是，IDE没有存储更改的快照，因此我必须从头开始。

另外，如果您不太熟悉要迁移的代码，则可能不知道要根据新准则更改的API的所有用法。

底线：进行人工检查时，请使用git UI工具和Xcode 8。

全部构建！

接受迁移工具所做的更改后，立即尝试构建项目。 当然有一些错误！ 默认情况下，Xcode在遇到构建错误时不会进行得太远。 在Xcode偏好设置中选择“出错后继续构建”。

我想再次强调这一步骤。 遍历构建并修复构建错误周期对于使项目启动和运行很重要。

Xcode 7.3.1回顾

Swift 3对iOS SDK进行了许多更改。 更改会破坏您的代码。 事实。 有时，不清楚如何正确迁移逻辑 。 我发现让Xcode 7.3.1到附近等待签出（现在是旧版）API，并了解必须采用哪种解决方法很有用。

但是，只有一个问题，在启动Xcode 7.3.1之前，必须关闭Xcode 8并清理所有缓存，反之亦然。

游乐场—名词：人们可以玩耍的地方

游乐场是检查事物运作方式的好工具。 每当我迁移非平凡的逻辑时，我都会对Playground进行快速测试。 与Xcode 7.3.1一起，Xcode 8 Playground对迁移有很大帮助。

私人叉子和勺子

这部分迁移值得一段落。

考虑一下人们在图书馆周围所做的现实生活：

• API的行为可能会发生变化，而无需更改API。
• API可能会更改，而不会更改行为。
• API和行为都可能改变。

另一方面，您的fork不一定能跟上它所源自的上游回购中所做的所有更改。 突然之间，它现在必须从上游撤出更改并重新应用其自己的私有“ hacks”。 这就是为什么周围的人建议您广泛进行更改并将其推向上游。

无论如何，请保持冷静并克隆上游仓库和您的叉子。 除了手动查看，比较，编辑，测试和提交之外，我不知道有什么更快的方法来分析您的更改如何适合其他代码库。 那就是我做到的。

人工审查

获得可构建的项目之后，是时候查看迁移助手为您做出的所有语法决策了。 这个过程可能很无聊，但必须有人来做。

待办事项

最初，我开始对以后需要重新审视的内容进行一些注释。 但是，后来，我决定将TODO放入具有特定格式的代码中（例如TODO：Swift 3： ）。 大概，这种方法将帮助我在项目中进行其他（相关）操作时对其进行研究。

结论

毕竟，在我遇到的情况下，Swift 3迁移有两个优点：

1. 我熟悉了（之前未知的）项目的代码库；
2. 我熟悉了Swift 3带来的所有变化。

…过程很有趣！