Swift对Objective-C应用的影响。

作为我在阿姆斯特丹软件公司Oberon实习的一部分，我最近将iOS应用程序的业务逻辑从Objective-C重写为Swift。 该应用程序是My T-Mobile。 当时的Swift版本是3.0。 除了重写业务逻辑之外，我还写了一篇关于Swift的影响的研究论文。

从上下文来看，自Swift 2.0发行以来，Swift现在是iOS上Oberon的事实上的开发语言。 由于My T-Mobile应用程序是Oberon上运行时间最长的应用程序之一，因此用Objective-C编写的应用占80％。 Oberon认为，当应用程序在Swift上运行时，软件质量将会提高。 因此，我不得不重写业务逻辑，因为它是应用程序中使用最频繁的部分，但是在自然的开发过程中不太可能被重写为Swift。

定义软件质量

对于我的Swift影响研究论文，我需要定义软件质量。 我决定使用CISQ（IT软件质量联盟）模型。 CISQ的标准基于ISO标准，但更强调源代码，因为我正在使用和重写源代码，所以源代码与我的项目非常匹配。

CISQ模型着重于四个特征：可靠性，性能效率，安全性和可维护性。

我决定专注于模型的可维护性方面，因为Swift的功能和标准对软件质量的那些方面影响最大：

  • 非结构化和重复的代码
  • 高圈复杂度
  • 文字的硬编码
  • 组件尺寸过大
  • 重复的业务逻辑
  • 符合初始架构设计
  • 架构层之间严格的调用层次

在本文中，我不会将重点放在这些点上，因为仅需一点上下文即可。

过程

因为懒惰的程序员是高效的程序员，所以我首先研究一下Objective-C-> Swift转换器。

有很多：

  • https://objectivec2swift.com/
  • https://iswift.org/
  • https://github.com/dzenbot/XCSwiftr

但是，他们每个人都有问题。 前两个选项不是免费的，一次只能转换几十行。 最后一个不能与Xcode 8一起使用，因为Xcode不推荐使用插件。

即使使用转换后的代码，我始终觉得这是从Objective-C到Swift的直接转换。 例如，转换器永远无法以显示防护语句或让模式提供更安全代码的方式来转换Objective-C代码。

需要考虑的另一件事是，Swift和Objective-C具有不同的编码范例，因此，通过使用转换器，将无法实现这一目标，并且还必须以某种方式检查和更改代码更迅速。 对于我来说，听起来比从头开始还需要做更多的工作。

简而言之，我决定手动重写和重构应用程序，而不是使用工具。

作为一个没有这个项目经验的人，很难理解代码。 例如，当使用诸如NSArray或NSDictionary之类的类型时，旧的Objective-C代码更难于推断进入了哪种对象。

在重构过程中，我注意到，随着函数和属性的类型被显式声明，尤其是对于数组和字典，它们的功能和属性变得更加清晰。

另一个优点是，与使用Objective-C两文件副本相比，Swift的单一文件使在整个项目窗口中导航更加轻松。

在重构了整个业务逻辑之后，我不得不找出它对软件质量有什么样的影响。
由于本文是关于使用Swift的影响，因此我决定使用一个名为SonarQube的工具，这是一个开放源代码平台，用于检查代码质量。

初始结果如下所示：

如您所见，可维护性，安全性和可靠性是完全相同的。 Swift版本减少了1000行代码，并且减少了重复，但是这些差异并没有真正使人震惊。 因此，我对SonarQube的发现进行了更深入的研究。

我发现以下内容：

如果您忽略了新的代码味道-当您不更改代码时就不会得到新的代码味道-您会发现Swift版本的代码味道比其Objective-C的更少。

我研究了一下代码的味道，发现Swift版本完全没有一种代码味道：认知复杂性。
认知复杂性试图在某种程度上说明方法的控制流程难以理解，从而难以维持。

SonarQube将上面的Objective-C代码片段标记为过于复杂，主要是因为它对嵌套逻辑进行了严格的评估。
Swift允许删除类型检查和null检查，而不会影响类型检查和null安全。 这样就大大降低了认知的复杂性。在Swift中不需要检查对象y是否是类x，因为函数中的指定参数永远不能是另一种类型（Swift中的类型安全）。

最后，从Objective-C重构应用程序为公司提供了许多优点，但也有缺点。

优点：

  • 在Swift中编写代码时，一种不那么容易产生代码异味。
  • 在我们这里，如今很难找到iOS开发人员，而新的iOS开发人员通常仅从Swift知识入手。 如果使用Swift编写，他们可以更轻松地接取项目。 在公司内部为iOS招聘开发人员时，Swift也比Objective-C少很多。
  • 开发人员能够在Swift中更快地接管项目，客户不会在知识转移上浪费很多时间，这反过来意味着开发人员能够更快地进行开发，从而为客户节省了资金。

缺点：

  • 重写的类需要重新测试。 这可能很耗时。
  • 一种是在重写类时容易出错。
  • Swift的新版本会定期发布，并且经常会有重大更改。 每年增加几次维护时间。 Objective-C作为一种语言是稳定的，并且十年来没有引入任何重大变化。

判决

对于Oberon的我们来说，这是值得的。 我收到了来自同事的非常积极的反馈，尤其是My T-Mobile的业务逻辑现在变得更加令人愉快。
此外，与Objective-C相比，几个同事在Swift方面更为熟练，这种转换使他们免于学习额外语言的投资。 基于SonarQube分析，我还要说该应用程序从可维护性的角度来看已经得到了改进。

尽管有这些积极的经验，我还是要提出一个警告。 我没有看过其他质量方面的内容，例如性能指标或安全性。 因此，出于可读性和可维护性之外的其他原因，我不能建议重写，即使在那儿，您的行程也可能会有所不同。

Interesting Posts