在杭州边还房贷边重构App：MVC、MVVM、VIPER我踩过的坑

上周五晚十一点，我坐在杭州城西89平的小书房里，对着Xcode一片飘红的编译错误发呆。房贷短信刚弹出来提醒我下月扣款一万二。脑子里就一个念头：这破代码，到底该不该推倒重来。

事情是这样的。我白天在一家跨境电商公司写iOS，晚上接私活——给连锁奶茶店做会员点单App。本想用最熟悉的MVC快速交付，结果需求越加越多：积分商城、拼团、优惠券核销、多门店切换……Controller胖到快三千行，改一处崩三处。

v0版本就是最初那个“能跑就行”的版本：View和Controller不分，网络请求直接写在ViewDidLoad里，Model用字典满天飞。当时安慰自己“后面再重构”，结果“后面”永远在下一个deadline之后。

真正让我下决心的是上个月深夜。老板打电话说iOS端优惠券不抵扣，安卓正常。我查了半天，发现某个Controller里一个布尔值在跳转时被意外重置，而这个Controller有二十多个入口。修了一个多小时，安卓那边十分钟就能搞定。

第二天周六，我七点爬起来打开电脑，给自己定下规矩：花两个周末，把核心模块从MVC迁到MVVM，同时抽出网络层和缓存层。VIPER暂时不用——私活体量没到那个复杂度，杀鸡用牛刀反而增加维护成本。

重构过程比想象痛苦。原来Controller里直接操作View的代码，要拆成ViewModel里的数据绑定；散落各处的UserDefaults读写，要统一到数据仓库层。我一边改一边骂自己当初为什么写这种代码。

优惠券模块原本Controller里同时处理网络请求、JSON解析、UI刷新、交互回调，四百多行。重构后ViewModel只暴露几个计算属性和方法，Controller瘦身到一百行出头。我还给ViewModel加了单元测试，以后改规则跑一遍测试就能发现哪里断了。

还有个意外收获。我要给App设计空状态插图，预算有限请不起设计师，就用Ideogram生成了几张奶茶主题插画，风格统一还挺可爱。客户看了直说“有内味儿了”。这让我意识到：架构重构不只是代码层面，资源管理和设计资产的引入方式都得一起考虑。

重构完那个周日晚上，我跑完回归测试，提交代码那一刻居然有种交房拿钥匙的错觉——代码的“产权”清晰了，哪些模块归谁管，一目了然。

现在回头看，MVC、MVVM、VIPER没有绝对优劣，关键看场景。MVC适合快速原型，但业务一复杂Controller就变成“上帝类”。MVVM是我最推荐的中间态，用数据绑定把View和逻辑解耦，学习成本不高，收益明显。VIPER适合大型团队协作，但文件多、上手慢，小项目用它纯属自找麻烦。

我总结了一条经验：架构不是选出来的，是长出来的。先用最简单的MVC跑通业务，等Controller开始失控、改一个bug要翻十几屏代码时，就是重构的信号。别等到积重难返才动手。

重构完那个月，老板又给我介绍了个新客户。他说：“你上次改的版本，店员都说好用多了。”我笑了笑，没告诉他我那两个周末掉了多少头发。

现在的我，每天下班还是会打开那个项目看看。房贷还在还，私活还在接，但至少代码不再让我做噩梦了。如果你也在纠结要不要重构，我的建议是：别等了，挑一个周末，从最痛的那个模块开始。你会感谢那个咬牙动手的自己的。