你的代码能运行,但这不代表不该动它
你写了一个应用,它能运行,客户满意,构建没有崩溃。看起来可以松一口气,去开发新功能了。但代码库内部却是一个弗兰肯斯坦式的怪物:300行的方法、复制粘贴、混乱的逻辑以及散落在项目各处的魔法数字。如果你曾有过“最好别碰这个类,否则一切都会崩”的想法——那么Swift代码重构对你来说不仅是一个建议,而是一种生存必需。
在本文中,我们将分析何时真正值得进行重构,以及何时最好保持代码不变。我将展示一些具体的Swift示例,你今天就可以应用。是的,没有废话——只有实践。
什么是重构,什么不是
从基础开始。Swift代码重构是在不改变程序外部行为的前提下,改变其内部结构的过程。你并没有添加新功能,也没有修复bug(尽管过程中经常会发现它们)。你只是让代码更干净、更易理解、更易于维护。
重要的是要理解:重构 ≠ 从头重写。如果你想扔掉整个项目,用SwiftUI和TCA架构重新开始——那不是重构,那是重写。而经验表明,重写在80%的情况下会以失败告终。
何时进行Swift代码重构:三个明确的信号
1. 三次法则(Rule of Three)
如果你第三次复制同一段代码——这是一个信号。不是第二次,而是第三次。第一次——没问题,你解决了问题。第二次——已经可疑,但可以归咎于匆忙。第三次——够了,编写一个通用解决方案。
// 糟糕:复制粘贴func formatUserName(_ name: String) -> String { return name.trimmingCharacters(in: .whitespaces).capitalized}
func formatProductName(_ name: String) -> String { return name.trimmingCharacters(in: .whitespaces).capitalized}
// 良好:统一方法func formatDisplayName(_ name: String) -> String { return name.trimmingCharacters(in: .whitespaces).capitalized}2. 长方法的“坏味道”
如果一个方法在手机屏幕上显示不全——那就有问题了。在Swift社区中,通常以每个方法15-20行为标准。当然,也有例外(复杂计算),但在95%的情况下,长方法意味着它做得太多。
3. 测试变成噩梦
当测试一个函数需要模拟5个服务、配置数据库并从磁盘读取文件时——这是一个危险信号。Swift代码重构应该让你的代码库更易于测试。如果现在写测试很痛苦——说明架构需要改变。
Swift重构的实践示例
让我们看看每个iOS开发者都会遇到的实际场景。
示例1:消除魔法数字
魔法数字是指没有上下文就无法理解其含义的数字字面量。它们使代码变得脆弱且难以阅读。
// 重构前func calculateDiscount(price: Double) -> Double { if price > 1000 { return price * 0.15 } else if price > 500 { return price * 0.1 } else { return price * 0.05 }}
// 重构后private struct DiscountConstants { static let premiumThreshold: Double = 1000 static let standardThreshold: Double = 500 static let premiumRate: Double = 0.15 static let standardRate: Double = 0.10 static let basicRate: Double = 0.05}
func calculateDiscount(price: Double) -> Double { switch price { case _ where price > DiscountConstants.premiumThreshold: return price * DiscountConstants.premiumRate case _ where price > DiscountConstants.standardThreshold: return price * DiscountConstants.standardRate default: return price * DiscountConstants.basicRate }}