为什么Swift的Code Review不是吹毛求疵
\n想象一下:你打开同事的拉取请求,看到500行Swift代码,而20分钟后就要开每日站会。熟悉吗?Code review(代码审查)不是“谁找到更多拼写错误”的比赛。这是你防止生产环境bug、改进架构、向团队传递知识的机会。
\n在这篇文章中,我整理了自己使用的Swift代码审查清单。没有废话——只有具体的检查项、代码示例以及为什么它们重要的解释。即使你写Python,但偶尔涉足iOS开发领域,这篇文章也会对你有帮助。
\n\n1. 内存安全与可选类型
\nSwift以其内存安全性为傲,但这并不意味着可以放松警惕。最常见的问题是强制解包。每个感叹号都代表潜在的崩溃。
\n\n检查什么:
\n- \n
- 强制解包(
!)——仅在测试中或当你100%确定值时允许。在生产代码中,这是一个危险信号。 \n - IUO(隐式解包可选类型)——仅用于IBOutlet或在
init之后、首次使用之前初始化的属性。 \n - 循环引用——检查闭包中是否使用了
[weak self]或[unowned self]。 \n
// 不好:未经检查的强制解包\nlet url = URL(string: "https://pythonlib.ru")! // 如果字符串无效,会崩溃\n\n// 好:使用guard let\nguard let url = URL(string: "https://pythonlib.ru") else {\n print("无效的URL")\n return\n}\n\n// 检查闭包中的循环引用\nclass NetworkManager {\n var completionHandler: (() -> Void)?\n \n func fetchData() {\n completionHandler = { [weak self] in\n guard let self = self else { return }\n self.updateUI() // self现在是弱引用\n }\n }\n \n func updateUI() { /* ... */ }\n}\n\n\n代码审查建议:如果看到!,就问“为什么这里不用guard或if let?”。这能避免许多崩溃。
2. 错误处理:不要吞掉异常
\nSwift提供了强大的do-catch机制,但开发者经常忽略它。典型的反模式是try!或空的catch。
检查什么:
\n- \n
try!——几乎总是有害的。除非你在写测试。 \n - 空的
catch {}——你只是丢失了错误信息。至少应该记录它。 \n - 向上抛出错误(
throws)——函数要么处理错误,要么明确地向上抛出。 \n
// 不好:吞掉错误\ndo {\n let data = try fetchData()\n} catch {\n // 什么都不做——错误丢失了\n}\n\n// 好:记录错误并向用户显示\ndo {\n let data = try fetchData()\n updateUI(with: data)\n} catch let error as NetworkError {\n showAlert(message: error.localizedDescription)\n} catch {\n print("未知错误:\\(error.localizedDescription)")\n showGenericError()\n}\n\n\n在Swift代码审查中,始终检查Error是否没有被简单地忽略。用户应该明白哪里出了问题。
3. 架构:MVC、MVVM还是VIPER?
\n不管你选择了哪种模式——重要的是代码要遵循它。在代码审查中,你要看ViewController是否变成了“上帝对象”(一个做所有事情的类)。
\n\n检查什么:
\n- \n
- 文件大小——如果单个文件超过300-400行,就应该考虑拆分。 \n
- 类的职责——ViewController不应该直接进行网络请求或解析JSON。这些应该由服务和管理器负责。 \n
博客
书籍推荐
推荐阅读