betway体育设计模式-《重构》读书笔记及 APP 重构心得。基于 MVC 的花色重构。

前段时间和同操同样于重构了片只
APP,正好想写一些重构心得,前天又在知乎上来看同一前辈推荐《重构》这仍开,据说是程序员的必读书籍,于是就简单的宣读了同合,对重构有矣重新怪层次之认识了。这里做
iOS 项目之重构,谈谈与重构相关的题目,做一下笔录和享受。

前言

多年来庄的品类只要创新具有界面的 UI
风格,趁此机会正好把品种重构一总体,本文主要记录重构时之一对抉择以及化解的题目。

同等、《重构》读书笔记

背景

首先说说背景,也便是为什么要重构,因为重构是内需成本的,一不小心修改错了,就会见于原本圆的成品来各种问题,所以先总结下何以,主要是以下四只问题:

  • 1.未曾统一之代码风格
    这就是于痛苦了,因为历史的原因,或者说这类型前期就无代码规范,在接项目前,代码风格就是非常自由、天马行空。在此期间我重构了同等片段,但按照有同不行半不正规的代码。
  • 2.臃肿的 ViewController
    是好明,一个类似几千执行代码,应该的莫应有的都挤在同。
  • 3.难知晓的逻辑代码
    事情逻辑代码混乱不堪,看之头疼,还不敢瞎删。
  • 4.混乱的类调用
    无明显一个好像该做啊,全都堆在一块儿。

追代码质量是一个佳绩程序员对团结之要求,所以就这个时,决定将所有项目重构一全勤。

1.1 重构的概念

  • “重构”这个词来三三两两种植不同之定义:
    • 先是单概念是名词形式:
      重构(名词):对软件内部结构的相同种植调整,目的是在非转移软件而察行为之前提下,提高其可理解性,降低该修改成本。
    • 第二只概念是动词形式:
      重构(动词):使用同样文山会海重构手法,在不移软件可观察行为之前提下,调整其布局。

重构的概念说明了少于点,第一,重构的目的是要是软件再爱为清楚和修改;第二,重构不见面变动软件而察的行事——重构之后软件功能还。

搭的挑三拣四

现阶段以 iOS 开发上生好多热门之架构模式,如 MVC、MVVM、MVCS、VIPER
等等。对斯我之意见是:架构的选而结合具体的事态,比如工作的复杂度、开发人员的接受程度,以及重构的时日周期等等,选择一个对的架比选一个苛的架更为重要。
以老项目里挑的凡 MVC,对于项目遭到之大举景吧,MVC
没有成制约业务发展的瓶颈,同时考虑到新品类之上成本及重构时间周期的问题,所以在新品类达到或选择了
MVC。

1.2 为何重构?

  • 重构可以扶持你总良好的控制好的代码,它好用来以下几单目的:

    • 重构改进软件设计
      设若没重构,程序的设计会日趋堕落变质。当众人才也短期目的,或是在一点一滴掌握整体计划前面,就愣修改代码,程序用逐年失去自己之布局,程序员越来越难以通过翻阅源码而亮原的计划性。
      完同样码业务,设计不良的顺序往往用再次多代码,这常是为代码在不同之地方用完全相同的语句做同样的作业。因此改进设计的一个重要趋势就是是破除重代码。

    • 重构使软件还便于掌握
      书写之前头来如此一句话:“任何一个白痴都能写起计算机可以知道的代码,唯有写来人类容易了解的代码,才是良好的程序员。”而重构可以使代码结构更清晰,使代码更易让清楚。

    • 重构帮助找到 bug
      本着代码进行重构,可以深入了解代码的作为,并当地把新的知道反馈回来,在重构的而,我们得窥见某些代码逻辑写的匪谨慎或有问题。

    • 重构提高编程速度
      精设计师维持软件开发速度之根本,重构可以辅助你又迅捷地开发软件,因为它们阻挡系统腐败变质,它甚至还好增进统筹质量。

合之代码风格

无规矩不化方圆,在总品种里由流程的欠以及开发人员的轮流,一直没一个合之编码规范。而在多人支付时,保持统一之编码规范是蛮有必不可少之,这样容易保持代码一致性和
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 项目重构心得

留空白

  • 建议用tabs
    而未是运用空格,tabs缩进使用4独空格,确保在Xcode偏好设置来装。
  • 文件截止时蓄一行空白
  • 于是足的空行把代码分割为合理的逻辑块,而无是坏窘迫凑
  • 永不以一行代码结尾处留空格
  • 再不用在空行(\n)中应用缩进(\t)

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
    控件,建议采取手工用代码来布局。方便之后的改动和复用。
  • 于急需发持续或组合关系之 UIView 类或 UIViewController
    类,建议用代码手工编制界面。
  • 于那些简单的、静态的、非主导作用界面,可以考虑用 xib 或
    storyboard 来就。

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

大体层级

上文确认了类别架构是以 MVC 为主,所以这边推荐下 MVC +
按工作划分项目层级的法子。具体的如下图:

betway体育 1

通项目重要分为4个文本夹,分别是:

  • AppDelegate: 程序入口。
  • Classes: 存放主要代码文件。
  • Resources: 存放资源文件,如图、音频、视频、 HTML 文件等。
  • Supporting Files: 存放配置文件,如 Info.plist、main.m、pch 文件等。

使中 Classes 目录下,又仔细分而下图:

betway体育 2

  • General:存放有通用的好像,如基类、Category、Model 等。
  • Sections:按工作模块细分 MVC。
  • Helpers:存放各种工具类。
  • Venders:存放需要手动引入的老三方库。
  • Macro:存放全局头文件,各种宏定义,常量等。

2.4 模块化设计

嘿是模块化?比如我们正开头码代码的当儿,有一个常用底措施(比如要算球面两接触里的偏离),由于是点子经常用,我们会将当下段代码用出来放到一个公共类里,以便实现代码的复用,这虽是大概的模块化。关于模块化设计之规格,一各项阿里大神的建议如下:

  • 尤为底层的模块,应该进一步稳定,越抽象,越有高复用度。
  • 并非为祥和的模块依赖不安静之模块, 减少因。
  • 每个模块只做好一码业务,不要为 Common
    出现(避免同一特别堆不系的代码放上一个模块)。
  • 比如架构的层数从上到下依赖,不要出现下层模块依赖上层模块的场面
    事情模块之间为尽可能不要耦合。

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

代码逻辑层级

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

  • 网络层:负责与服务器通讯获取数据。
  • 数据层:存储用户的数码,包括外存cache。
  • 业务层:包含各种业务逻辑。
  • UI数据层:负责提供UI层所欲的数量,UI只和这层打交道。
  • UI层:包括ViewController和View,处理用户之输入。

旁使项目重复清楚,开发时好逐层独立,高内聚、低耦合。

2.5 代码规范

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

  • 取名规范
    iOS
    命名第一注意少独面,第一凡是可读性强,别人一样看这个名字就是了解她的义和作用;第二凡防命名冲突,命名时应以驼峰式命名法则,另外如加前缀,比如常量命名一般会以前头加上字母
    k。

  • 编码规范
    关于编码规范来好多细节要专注,比如函数方法一般不能够过长;比如实例变量的修饰符要小心;再以尽可能确保
    .h 文件精简,API
    尽量写于贯彻公文里……编码时还发出其他一些当小心的,比如写
    delegate 的当儿路应该吗
    weak,以避免循环引用;再按经典的圆角问题,过多的利用
    layer.masksToBounds
    对系的支出非常非常,会如页面变的卡顿等等……这些编码细节产生那么些索要留意,就不一一列举了。

  • 写注释
    形容注释写注释写注释,重要之事情说其三整整。注释可以帮忙任何同事又好的明亮您勾勒的代码,还好温馨后的读书。

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

再也安利一本书,《编写高质量 iOS 与 OS X 代码的 52
只有效措施》,这按照开对编码时许小心的细节刻画的充分到,之前读了一样方方面面,过几龙会另行念一所有,并记下。

布局规范

AutoLayout

尽色是纯 Frame 布局,代码里发生同等不行堆 Magic
Number,一可怜堆屏幕尺寸判断,而这些造成了类别里有过多的布局代码,对于刚刚上手项目的食指吧也未极端爱看懂。所以这次重构整体采用
AutoLayout 布局,摒弃老色里的纯 Frame 布局方式,精简代码。

Xib/Storyboard

亲手写 UI 和 Xib/Storyboard 谁优谁劣这里不开讨论,但生一样碰我道
Xib/Storyboard 是比手写 UI
要抢之。而这次重构工作量非常工期紧,所以弃老品种里的手写 UI ,改用
Xib/Storyboard 。

精简 ViewController

眼看无异于有些自看是本次重构的关键性,也是此次重构的基本点目的所在,精简
ViewController 里的代码betway体育,解决老品种面临 Massive ViewController 的问题。
要工作分为以下几步:

  • 1.保留最重大之职责,拆分其它非重要的任务。
  • 2.拆分开后的模块要尽可能提高而复用性,尽量做到DRY
  • 3.增长拆分模块后的抽象度

胖 Model 的问题

上文精简 ViewController 把代码都在到 Model 里去,所以会见促成胖 Model
的题目。对这个我的接头是,除了优化外,代码的总量是确定的,一正值的简短必然会导致同正的加码,而
Model 在此地是为此来帮 ViewController 处理工作逻辑的,也就是说胖 Model
包含了一部分弱业务逻辑。胖 Model 要达成的目的是,Controller从胖 Model
这里用到数以后,不用额外做操作还是只要做很少的操作,就能用数据直接行使在
View 上,从立点及看胖 Model 也是可以领之。

单元测试

老品种是免写测试代码的,也没写单元测试的尺码。想想一个类堆砌几千执代码,想写吗坏下手,但既然重构了,单元测试也得上上。
单元测试对于目前吧,就是为着便于测试一些作用是否健康运行,还有调试接口是否会正常下。
偶然你恐怕是为测试某一个网络接口,然后每次都更启航以通过广大操作之后才测试到了挺网络接口,如果用了单元测试,就足以直接测试好方式,相对好广大。
按照由于修改比较多,想测试一下享受功能是否正常,这时候就产生因此了。或者直接扣有些接口返回的数额为会见要命直观,不用启动全套工程。

TODO

每当这为列举两单连下去好举行的行,先补充加到 ToDoList 里。

  • URLRoute

  • 模块化

最后

实际上总结起来就是三碰,尽量确保:

  • Controller 里的代码尽可能的遗失
  • Model 的作用尽可能的完好
  • View 尽可能独立

就会构建一个爱保障,便于协同的型。

正文只是以档次重构中总结的局部比较重大之触及,并无代表都是无限优解。而自己在路的架构和代码的团伙达经历尚浅,若本文有啊错可能有双重好的方式要直接指出,欢迎交流讨论。

Reference

iOS应用架构谈
view层的社及调用方案

相关文章

发表评论

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

*
*
Website