在相亲第13次后，我用VIPER架构理清了自己的感情线

上周六晚上，我和小陈坐在杭州滨江那家叫“代码咖啡”的小店里。她是我第13个相亲对象，之前12个基本都在“你写代码是不是很无聊”这个问题后没了下文。但小陈不一样，她问的是：“你们iOS开发现在都用什么架构？”我愣了一下，然后笑了。那一刻，我突然觉得，这个女孩可能真的能理解我。

从MVC开始，就像我最初的恋爱观

2019年我刚入行，在南京一家小公司做iOS开发。MVC（Model-View-Controller）真的很直观，就像我当时的恋爱观——简单直接。但问题很快就来了。一个电商App首页，ViewController里塞了3000多行代码，网络请求、UI布局、数据处理全挤在一起。老板让我加个新功能，我改了一个星期，结果把购物车改崩了。MVC的Massive ViewController问题，就像相亲时把所有期待都压在第一次见面——聊得太多，反而容易搞砸。

MVVM让我学会了“双向奔赴”

2021年我跳槽到杭州，新公司用MVVM（Model-View-ViewModel）。ViewModel把业务逻辑抽离，View和Model通过数据绑定通信，就像相亲里的“双向奔赴”——你无需猜测，数据流是透明的。用RxSwift做绑定时，一个登录页面，View只负责展示，ViewModel处理验证逻辑，代码量少了40%。但也易踩坑：复杂页面下，ViewModel会变得臃肿。就像我和第8个相亲对象，聊得挺好，但总感觉少了点什么——职责不够清晰。

VIPER：一场严格但有效的“情感分工”

真正让我开窍的是VIPER。去年十月，公司要重构老项目，技术总监老周让我们尝试VIPER（View-Interactor-Presenter-Entity-Router）。一开始我是拒绝的——五个模块，文件数量暴增。但硬着头皮用了三个月后，我发现它真的香。每个模块职责明确：View只管显示，Interactor处理业务，Presenter做中间人，Entity是数据模型，Router负责跳转。就像一场成熟的感情，每个人都知道自己该做什么。

去年12月，产品经理临时加了个“AI视频”功能。用AI工具分析现有VIPER模块，它能直接给出Interactor里该加什么方法，Presenter怎么调。但代价也明显：一个小功能要建五个文件。老周说：“这就跟谈恋爱一样，前期投入大，但后期维护成本低。”今年3月我们加新功能，改bug的时间少了60%。

GitHub Spark和我的“架构焦虑”

最近我在用GitHub Spark做原型开发，描述需求就能生成代码，但复杂业务逻辑还得自己写。这让我想到：架构到底是工具决定的，还是业务决定的？MVC适合快速开发小项目，就像年轻时随便谈个恋爱；MVVM平衡了复杂度和维护性；VIPER适合长期维护的大型项目，就像奔着结婚去的感情。技术选型没有银弹，关键是你当前的需求。我现在负责的项目有50多个页面，十几个开发者，VIPER的严格分工让协作顺畅很多。

在架构里找到自己的节奏

今年6月，我开始认真考虑回老家合肥发展。合肥有家公司给了offer，薪资少一点，但离家近。我跟小陈说了，她沉默了一会儿，然后说：“不管你选什么架构，重要的是代码能跑起来，生活也是。”这句话点醒了我。技术架构的选择，本质上是一种价值观的体现。MVC的自由、MVVM的平衡、VIPER的严谨，没有对错，只有适不适合。就像我经历了13次相亲才遇到小陈，不是因为前面的不好，而是我终于知道自己要什么。

说到底，写代码和谈恋爱一样，工具能帮你提高效率，但真正重要的，是你对问题的理解和对选择的负责。如果你也在纠结iOS架构选型，我的建议是：先搞清楚项目规模和团队能力，然后选一个大家都能接受的方案。别被“最佳实践”绑架，也别盲目追新。就像相亲，别总想着下一个更好，有时候，适合你的就是最好的。