菜单

设计模式-《重构》读书笔记及 APP 重构心得。基于 MVC 的类别重构。

2018年9月22日 - betway官网手机版

前段时间和共业同样由重构了零星个
APP,正好想写有重构心得,前天又当知乎上收看同样前辈推荐《重构》这本开,据说是程序员的必读书籍,于是就概括的念了扳平满,对重构有了再甚层次之认了。这里做
iOS 项目之重构,谈谈与重构相关的题目,做一下记下与享受。

前言

不久前合作社的类如更新具有界面的 UI
风格,趁此机会正好把路重构一全体,本文主要记录重构时之有的精选与化解的问题。

同等、《重构》读书笔记

背景

第一说说背景,也就算是为什么要重构,因为重构是亟需资本的,一不小心修改错了,就会为本圆的制品产生各种问题,所以先总结下怎么,主要是以下四个问题:

追求代码质量是一个脍炙人口程序员对自己的渴求,所以趁着这机遇,决定拿整项目重构一整个。

1.1 重构的定义

重构的概念说明了片触及,第一,重构的目的是要软件再易于为了解和修改;第二,重构不见面改软件而察的一言一行——重构之后软件功能依然。

搭的选项

脚下于 iOS 开发上有那么些热之架构模式,如 MVC、MVVM、MVCS、VIPER
等等。对之我之理念是:架构的挑三拣四而成具体的动静,比如工作的复杂度、开发人员的接受程度,以及重构的时空周期等等,选择一个针对性之架比选一个苛的架构更为重要。
在镇色里挑的是 MVC,对于项目面临之大举景吧,MVC
没有成为制约业务发展之瓶颈,同时考虑到新路之就学成本以及重构时间周期的题目,所以当初路达到还是选择了
MVC。

1.2 为何重构?

联合的代码风格

无规矩不化方圆,在镇色里由流程的欠及开发人员的更迭,一直尚未一个集合之编码规范。而在差不多人口付出时,保持统一的编码规范是深有必不可少的,这样好保持代码一致性与
Code Review。所以确定了架之后,接着就是确定编码规范。
脚是编码规范里有急需小心的触及:

1.3 何时重构?

命名

动可读的驼峰命名法去给类、方法、变量命名。
常量应该利用驼峰式命名规则,所有的无非词首配母大写及增长和类名有关的前缀。

1.4 重构的中坚技能:

代码分块

在函数分组和protocol/delegate实现中动用#pragma mark
-来分类方法,要准以下一般结构:

#pragma mark - Lifecycle

- (instancetype)init {}
- (void)dealloc {}
- (void)viewDidLoad {}
- (void)viewWillAppear:(BOOL)animated {}
- (void)didReceiveMemoryWarning {}

#pragma mark - Custom Accessors

- (void)setCustomProperty:(id)value {}
- (id)customProperty {}

#pragma mark - IBActions

- (IBAction)submitData:(id)sender {}

#pragma mark - Public

- (void)publicMethod {}

#pragma mark - Private

- (void)privateMethod {}

#pragma mark - Protocol conformance

第二、结合 iOS 项目重构心得

留空白

2.1 项目目录结构

种之目录结构是付出中极基础之,但为是老关键之,清晰的目录结构能被人一致眼睛就扣留明白该品种之事体以及作用,目录结构为能够影响一个开发者的经历与架构水平。项目目录结构较健康的起零星栽,第一栽是据工作分类,第二种是随模块分类。当然具体还得根据实际的作业需求来开,适合自己的才是最好的。

此出一样首关于项目目录结构的稿子,有趣味的童鞋可以读下:iOS
项目的目录结构能望你的开发经历

代码块缩进

(if/else/switch/while etc.)或者method function
的大括如泣如诉留于此时此刻实行,并前保留一个空格 ,能大概的不用添加

if user.isHappy {
  // Do something
} else {
  // Do something else
}

不推荐

if (user.isHappy )          多余空格
{                  换行位置不对
  // Do something
}
else {
  // Do something else
}

2.2 业务与 UI

这边不讨论 MVC 架构和 MVVM
架构,关于架构模式之间的争辩有诸多,个人于支持一个理念:永不局限为
MVC、MVVM、MVP
等等一些架模式,万变不离其宗,真正适用于路之架构才是最为好之架构。刚巧接手的原本路在筹划初期及支付过程中,没有进展客观之计划性,以至于部分控制器过于臃肿,代码量很多都是跨了
1000 行,有的还逾越了 1500
行,而且写的深乱。重构的目的,就是增强代码的可读性和方便以后的掩护,我这里论
MVC 的架构模式,将 UI
部分开展抽离,将工具代码(比如计算球面两点之间的距离)进行包装,并内置了有关的家伙类吃,又针对控制器中之冗余代码进行了整理,使得控制器中之代码减少及前的三分之一以下。分享同布置
cocoa 上的 MVC 架构图:

MVC 架构

花色层级细分

2.3 代码还是 xib、 storyboard?

描绘 UI 界面用代码还是用 xib 一直是 iOS
界的争执,有的人支持被采取代码,有的人赞成被用
xib,巧神之前以博客中也讨论过是题目,并于出了部分建议(个人于赞同):

此间是巧神关于写 UI 用代码还是用 xib 的系讨论: iOS
开发中之争执(二)

物理层级

上文确认了档次架构是盖 MVC 为主,所以这里推荐应用 MVC +
按工作划分项目层级的办法。具体的如下图:

图片 1

任何项目根本分为4独文件夹,分别是:

一旦内部 Classes 目录下,又密切分而下图:

图片 2

2.4 模块化设计

哟是模块化?比如我们正开码代码的时光,有一个经常用之方(比如要合算球面两接触期间的离),由于这个主意经常用,我们会将当下段代码用出来放到一个公共类里,以便实现代码的复用,这就是简简单单的模块化。关于模块化设计之标准,一员阿里大神的提议如下:

针对模块化设计感兴趣之童鞋可以看下这首文章,绝对干货!模块化与解耦

代码逻辑层级

于代码逻辑上,大致分成 5 层

分使项目再度鲜明,开发时好逐层独立,高内聚、低耦合。

2.5 代码规范

至于代码规范,每个程序员遵守的代码规范多多少少且见面有点不同(比如什么时候该空格,常量变量的命名方式等等),之前听一前辈说了,尽量遵循那些“约定俗成”的代码规范,另外在编码时,要保管自己之代码规范总同,别为丁一样种植你写的代码是几只人口联合写的错觉。

代码规范方,这里也引进一篇对的文章:iOS开发-代码细节优化(长期更新)

复安利一本书,《编写高质量 iOS 与 OS X 代码的 52
个有效方法》,这按照开对编码时许小心的底细刻画的可怜周全,之前读了相同所有,过几龙会再念一整整,并记下。

布局规范

AutoLayout

始终品种是纯 Frame 布局,代码里产生相同可怜堆 Magic
Number,一很堆屏幕尺寸判断,而这些导致了项目里来了多之布局代码,对于正上手项目之总人口的话吧不顶好看懂。所以这次重构整体应用
AutoLayout 布局,摒弃老品种里之纯 Frame 布局方式,精简代码。

Xib/Storyboard

手写 UI 和 Xib/Storyboard 谁优谁劣这里不举行讨论,但产生同等碰自己觉着
Xib/Storyboard 是比手写 UI
要赶快之。而这次重构工作量特别工期紧,所以弃老项目里的手写 UI ,改用
Xib/Storyboard 。

精简 ViewController

就等同有的自己认为是此次重构的基点,也是本次重构的重要性目的所在,精简
ViewController 里的代码,解决老项目蒙 Massive ViewController 的题目。
重要办事分为以下几步:

胖 Model 的问题

上文精简 ViewController 把代码都投入到 Model 里去,所以会造成胖 Model
的题材。对这个我之解是,除了优化外,代码的总量是确定的,一着的凝练必然会招致同正在的加码,而
Model 在这边是因此来帮 ViewController 处理业务逻辑的,也就是说胖 Model
包含了有的弱业务逻辑。胖 Model 要达到的目的是,Controller于胖 Model
这里拿到数码后,不用额外做操作还是如做老少之操作,就能以数据直接用在
View 上,从当时点达到看胖 Model 也是足以接受的。

单元测试

总项目是无写测试代码的,也从来不写单元测试的尺度。想想一个类堆砌几千尽代码,想写吧不好下手,但既然重构了,单元测试也得添及。
单元测试对于眼前吧,就是为了有利于测试一些效果是否正规运转,还有调试接口是否能健康下。
有时你也许是以测试某一个网络接口,然后每次都还起动以经过无数操作下才测试到了那个网络接口,如果下了单元测试,就得一直测试大方式,相对有利多。
仍由于修改比较多,想测试一下享受功能是否正规,这时候就闹因此了。或者直接看有些接口返回的数额吧会大直观,不用启动全套工程。

TODO

在当下吗列举两只对接下好做的从,先上加至 ToDoList 里。

最后

实际上总结起来便三碰,尽量保证:

不畏可知构建一个容易保障,便于协同的类别。

本文只是在档次重构中总的局部较根本的触发,并无意味着都是极端优解。而自我于列之架和代码的团组织上涉尚浅,若本文有什么错误或有重好之计要直接指出,欢迎交流座谈。

Reference

iOS应用架构谈
view层的团队以及调用方案

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图