设计模式-《重构》读书笔记及 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 +
按工作划分项目层级的法子。具体的如下图:

2019亚洲杯 1

整项目重要分为4单文件夹,分别是:

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

而里边 Classes 目录下,又密切分而下图:

2019亚洲杯 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,一特别堆屏幕尺寸判断,而这些导致了种里发出过多之布局代码,对于刚刚上手项目的口吧吧不绝爱看懂。所以这次重构2019亚洲杯整体应用
AutoLayout 布局,摒弃老项目里之纯 Frame 布局方式,精简代码。

Xib/Storyboard

亲手写 UI 和 Xib/Storyboard 谁优谁劣这里不做讨论,但出一样碰自己认为
Xib/Storyboard 是比手写 UI
要抢之。而这次重构工作量特别工期紧,所以弃老色里之手写 UI ,改用
Xib/Storyboard 。

精简 ViewController

立马无异于有些自觉着是本次重构的基本点,也是此次重构的要目的所在,精简
ViewController 里的代码,解决老项目蒙 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层的社以及调用方案

相关文章