Clean Code 在 Swift 中的实践：iOS/macOS 开发原则与示例

Clean Code 在 Swift 中：为什么 iOS 开发者需要它

每个开发者都遇到过这种情况：旧代码一个月后就变成了"意大利面条"。在 Swift 的世界里，项目增长迅速，保持代码整洁变得至关重要。Clean Code 不仅仅是美学问题，更是一种工具，它能节省数小时的调试时间，并简化新功能的添加。在本文中，我们将结合 iOS 和 macOS 的实际示例，分析 Clean Code 在 Swift 中的关键原则。

1. 命名：可读性优先

正确的命名是整洁代码的基础。在 Swift 中，API 通常是自文档化的，糟糕的命名是混乱的主要来源。

糟糕的示例：

class DataManager {    func getData() -> [String: Any] {        // ...    }}

良好的示例：

class UserProfileFetcher {    func fetchUserProfile(for userID: String) -> Result<UserProfile, NetworkError> {        // ...    }}

• 对方法使用动词（fetch, update, delete）。
• 避免缩写——vc, btn, str 已经是过去式了。
• 布尔变量应该读起来像陈述句：isLoggedIn, hasNetworkConnection。

2. 函数：小而专一

在 Swift 中，闭包和函数式编程很流行，很容易沉迷其中并写出一个庞大的函数。单一职责原则（Single Responsibility）在这里百分之百适用。

糟糕的示例：

func processUserData(user: User) {    // 验证    if user.email.isEmpty { return }    // 保存到 CoreData    CoreDataStack.shared.save(user)    // 发送到服务器    APIClient.shared.send(user)    // 更新 UI    DispatchQueue.main.async {        self.tableView.reloadData()    }}

良好的示例（拆分为小函数）：

func processUserData(user: User) {    guard validateUser(user) else { return }    saveUserLocally(user)    sendUserToServer(user)    updateUI()}

private func validateUser(_ user: User) -> Bool {    return !user.email.isEmpty}

private func saveUserLocally(_ user: User) {    CoreDataStack.shared.save(user)}

private func sendUserToServer(_ user: User) {    APIClient.shared.send(user)}

private func updateUI() {    DispatchQueue.main.async {        self.tableView.reloadData()    }}

20 行规则：如果一个函数不能在一屏内显示完，就拆分它。每个函数应该只做一件事。

3. Swift 中的 SOLID：实际示例

SOLID 原则不是抽象概念，而是实用的工具。我们来分析两个对 iOS 至关重要的原则。

开闭原则（Open/Closed）

类应该对扩展开放，对修改关闭。与其修改一个已经完成的类，不如使用协议。

protocol PaymentProcessor {    func process(amount: Double, currency: String) -> Bool}

class ApplePayProcessor: PaymentProcessor {    func process(amount: Double, currency: String) -> Bool {        // Apple Pay 逻辑        return true    }}

class StripeProcessor: PaymentProcessor {    func process(amount: Double, currency: String) -> Bool {        // Stripe 逻辑        return true    }}

// 现在要添加新的支付方式——只需创建一个新类，无需改动旧类。

里氏替换原则（Liskov Substitution）

子类不应破坏父类的逻辑。一个典型的错误是重写方法时改变了约定。

class Vehicle {    func startEngine() {        print("Engine started")    }}

class ElectricCar: Vehicle {    override func startEngine() {        // 违反：电动