项目重构实践之iOS客户端

程序员 2024-9-21 05:30:50 67 0 来自 中国
1.jpg 一、项目熟悉

在重构项目之前起首是要对项目标业务和项目架构有肯定的熟悉程度才气更好的举行对项目重构的一个实行过程。因此我花了将近一个多月到两个月的时间在熟悉项目代码和业务上,在领到和同事的资助下对整个项目也有了一个更深度的了解和熟悉。也意思到重构这件变乱更是如饥似渴。
此中做开发这块重构项目这件变乱是常有的变乱也是必须要去做的变乱,只不外大概思量到资本和效益的缘故原由不愿定肯投入时间和精神去做,实在否则,这件事做好了对项目标一个以后应对业务的不停扩展和发展都是利大于弊的,固然肯定是要在有个好的重构根本之上才行
二、优化根本代码

在熟悉代码的过程中,你大概就是会发今世码的优缺点,优点的话我们就继续保持,缺点这块就是我们可以优化的地方。
比方装备状态这块,可以利用罗列一览无余是什么状态,而不是一大堆的数字对应不上。又比如基类,偶然候为了方便我们很容易就把不应该出如今基类里的方法给添加进去,久而久之基类就变大痴肥无比。以是把方法放到得当的地方去,减轻基类压力。另有就是假如代码重复高出三次我们就应该思量抽出来处置惩罚,代码复用这块可以不停优化中。我们在界说一个方法中只管不要让他的行数高出一个面板,而且最好让他处置惩罚单一的变乱,能拆分出来的只管拆分出来。末了就是AppDelegate类的优化处置惩罚,之前在didFinishLaunchingWithOptions方法中实今世码太长而且很紊乱,如今将每个要加载的功能都抽出来,简便清新许多,修改的时间也不容易出题目。
目前这些是我在熟悉代码过程中自己发现的一些题目,实在后面陆连续续在重构过程中也发现了不少题目,也就不逐一列举,总的来说就是对代码可以反复的去阅读去推敲看看是否公道有没有优化的地方
三、选择符合的架构

目前项目上利用的是mvc,不外也没有那么严格,导致c层逐步开始变的痴肥起来,而且和视图层耦合度相对比力高,通过小组的讨论和分析,决定利用mvp架构处置惩罚,mvp架构的上风一个上手快,团队上手没有什么学习资本,第二个就是对于业务逻辑和UI视图的解耦本事结果显着,通过泛型和协议可以将View层和业务P层举行完全的解耦处置惩罚,这实在就是我们目前很希望的样子,以是终极是选择MVP这个架构,在架构处置惩罚的过程中也对业务逻辑和UI逻辑有了更深的了解。
四、对项目举行分层处置惩罚

项目分层分好了可以更好的应对上层需求的变革,大抵我们分层了根本层,SDK层,业务层、UI层。
根本层:这里提供一些根本的功能,分类,宏界说,设置列表,和一些工具类
SDK层:这里告急是封装了阿里云端sdk,通过二次封装举行隔离,便于更换其他库和库的更新等等
业务层:根据差异业务线举行拆分出多条业务,都属于同一层
UI层:这里就是视图层,变革比力多,一样寻常就在主工程里的UIView 和 UIViewcontroller
五、通过私有cocoapods管理

在分好层的根本上我们引入cocoapods管理工具举行管理,创建私有库,并将根本层、sdk层、业务层、封装成pod库,提供给各个项目利用,如许比如有业务逻辑题目就不要每个项目都去改一遍,只要将库更新,其他项目拉去最新库即可完成修复,UI层这边是多变的一样寻常就不消打包成库,直接在主工程里修改即可。
六、通过中央件CTMediator 举行模块化通讯实践

当一个项目越来越大以后,不可制止的要去实现模块化解耦通讯工作。目前告急模块通讯有两种方式,url注册和TargetActions,通过调研利用TargetActions更符合,通过CTMediator可以再当地模块间通讯和长途app间举行通讯处置惩罚。而且他是通过runtime机制举行完全解耦隔离,唯一不敷就是在分类和Target上有些硬编码,不外还是在可控制范围。目前在首页跳转配网模块和首页跳转面板模块举行了实践。
七、 总结

重构项目目前已经靠近尾声,后续另有许多待改进和美满的地方。对应mvp的缺陷带来的p层的痴肥这个是以后要面临和去优化的点,另有就是在现有mvp根本上看看能不能引入双向绑定,如许状态的一个同步能有更好的实现结果。另有就是根本层的库的一个沉淀,业务库的一个美满等等
通过几个月的一个重构处置惩罚,根本上是到达之前的预期,从中也有不少的收货。
您需要登录后才可以回帖 登录 | 立即注册

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-10-18 22:34, Processed in 0.173781 second(s), 35 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表