最近入职了新公司，刷新我从业以后对于iOS代码的观念。从项目设计模式的框架、代码量、内存管理，耦合度等等都见识了技术层面的下限（也许是我见识浅薄🤔）。故此总结一下，自警避免重蹈覆辙。

项目介绍

项目是非常规功能性App，个人理解老板的愿景是构建一个物联网平台，后期可以应用到写字楼显示屏以及用户个人设备上，实现天气、交通、股票、购物等等各种民生服务可视化。首页为地图背景，由后台返回环境元素素材，模拟用户周边环境，机器人问答检索用户输入信息并反馈。

代码槽点

最让我惊诧的“无”设计模式

项目结构主要是一个主控制器，不同页面以新建UIView类页面（个人理解应该以childVC形式），且只有两个分页面的模型。也就代表主控制器承载了数据解析、逻辑判断、事件监测等所有任务，数据的输入输出大部分也是以字典关键词进行索引。

坚持就是胜利的代码量

主页面有一万五千行代码，其余分视图也有几百到几千行代码不等，一个方法几千行代码，一个if判断跨越几百行代码，if判断一个套一个，连绵不绝。

随遇而安的内存管理

内存管理杂乱无章，很多block随机self弱引用（部分是局部变量的block），大部分页面没有delloc方法的释放处理。最主要的问题是AFN没有采用单例模式，导致大量的内存泄露（经过几天排查以及查资料才找到）。

设备适配靠慧眼

视图的适配基本是写死的固定数值，以及复杂的系数乘除法。使用Masonry也基本是固定数值，且大量约束冲突。

冗余余余余余余代码

所有页面伴随大量冗余代码，譬如气泡元素十数个挨个创建和约束，难道一个for循环不香吗？🤷‍♀️，再比如一段局部代码，在一个文件内重复N次，复制和单写一个方法一行代码解决哪个更简单？🤷‍♀️

千丝万缕的耦合度

文件内充斥大量的无参方法和巨量的全局变量，以及视图之间互相引用（更甚之，该页面的逻辑会写到其他页面中）

重复啰嗦的帮助类

估计该项目应该经过多人手，大量命名不规范且无法复用的帮助类。单一功能性的扩展（我真害怕有runtime置换个原生方法，那就欲哭无泪了）。项目目录也很杂乱，帮助类随意放置。

这一次真的是刷新iOS从业以来的技术认知下限，但是也是警醒自己在项目框架以及细节处理上要吸收经验，避免自己的代码被人接手后大喊傻逼。代码这东西很抽象，可能真正踩过坑，才会意识到代码规范和架构的重要性。入职至今将近一个月，老板不断地催促开发新功能，旧代码也并没有完全理顺，但也是一个成长的过程，以此记录和总结。