正文主要记录重构时的片段摘取和化解的题目,清晰的目录结构可以令人一眼就看懂该类型的事体及效益

1.1 重构的概念

  • “重构”这些词有三种差距的概念:
    • 首先个概念是名词形式:
      重构(名词):对软件内部结构的一种调动,目标是在不改动软件可观望行为的前提下,升高其可领悟性,下落其修改费用。
    • 第三个概念是动词方式:
      重构(动词):使用一文山会海重构手法,在不改变软件可观望行为的前提下,调整其布局。

重构的概念表明了两点,第一,重构的目的是使软件更便于被通晓和改动;第二,重构不会转移软件可观望的行事——重构之后软件效能仍然。

Reference

iOS应用架构谈
view层的团体和调用方案

2.3 代码依然 xib、 storyboard?

写 UI 界面用代码如故用 xib 一贯是 iOS
界的争辨,有的人倾向于选取代码,有的人辅助于采取xib,巧神从前在博客中也商量过那些题材,并付诸了部分提出(个人相比较赞同):

  • 对于复杂的、动态变化的界面,提出利用手工编制界面。
  • 对于需求统一风格的按钮或 UI
    控件,指出利用手工用代码来社团。方便之后的修改和复用。
  • 对于须求有接二连三或结成关系的 UIView 类或 UIViewController
    类,指出用代码手工编制界面。
  • 对于那个不难的、静态的、非焦点效用界面,可以考虑拔取 xib 或
    storyboard 来形成。

此处是巧神关于写 UI 用代码仍旧用 xib 的相关研商: iOS
开发中的争议(二)

架构的挑三拣四

眼前在 iOS 开发上有很多热点的架构方式,如 MVC、MVVM、MVCS、VIPER
等等。对此我的意见是:架构的采取要结合具体的图景,比如工作的复杂度、开发人士的接受程度,以及重构的大运周期等等,选拔一个对的架构比选拔一个复杂的架构更为主要。
在老品种里甄选的是 MVC,对于项目中的绝半数以上光景来说,MVC
没有成为制约业务发展的瓶颈,同时考虑到新品类的就学习话费用以及重构时间周期的问题,所以在新类型上或者选用了
MVC。

2.4 模块化设计

怎么样是模块化?比如大家刚开始码代码的时候,有一个时常用的法门(比如仍然合算球面两点时期的偏离),由于那些点子平时用,大家会把那段代码拿出来放到一个公共类里,以便完结代码的复用,那就是简单的模块化。关于模块化设计的标准,一位阿里大神的提出如下:

  • 越底层的模块,应该越稳定,越抽象,越具有高复开支。
  • 无须让祥和的模块信赖不平静的模块, 减弱着重。
  • 每个模块只做好一件事情,不要让 Common
    出现(幸免一大堆不相干的代码放进一个模块)。
  • 根据架构的层数从上到下看重,不要出现下层模块信赖上层模块的气象
    作业模块之间也硬着头皮不要耦合。

对模块化设计感兴趣的童鞋可以看下那篇小说,相对干货!模块化与解耦

TODO

在那也列举七个接下去可以做的事,先添加到 ToDoList 里。

  • URLRoute

  • 模块化

一、《重构》读书笔记

代码逻辑层级

从代码逻辑上,大概分为 5 层

  • 网络层:负责和服务器通信获取数据。
  • 数据层:存储用户的多寡,包涵内存cache。
  • 业务层:蕴含各类业务逻辑。
  • UI数据层:负责提供UI层所必要的数额,UI只和那层打交道。
  • UI层:包罗ViewController和View,处理用户的输入。

分层使项目更清晰,开发时成功各类层独立,高内聚、低耦合。

1.4 重构的中央技术:

  • 小步前进、频仍测试

Xib/Storyboard

手写 UI 和 Xib/Storyboard 何人优什么人劣那里不做商讨,但有一点我觉着
Xib/Storyboard 是比手写 UI
要快的。而本次重构工作量大工期紧,所以扬弃老品种里的手写 UI ,改用
Xib/Storyboard 。

1.3 曾几何时重构?

  • 怎么着布置重构时间表?是还是不是应有每七个月就更加安排四个礼拜来举办重构呢?那里须要验证,重构不是一件理当尤其拨出时间做的事务,重构应该随时遍地举办。不应有为重构而重构,大家就此重构,是因为想做其余事情,而重构可以帮助大家把那个事做好。

    • 五次法则(事但是三,三则重构)
      第三遍做某件事时只管去做;第二次做类似的工作会生出反感,但还能去做;第二回再做类似的业务,就应该重构了。

    • 累加效劳时重构
      最常见的重构时机就是我们想给软件添加新特点的时候,此时,重构的直接原因往往是为着救助大家领略要求修改的代码——那些代码可能是别人写的,也恐怕是自己写的。

    • 修补错误时重构
      调剂进程中重构,多半是为了让代码更具备可读性。

    • 复审代码时重构
      代码复审对于编写清晰代码很重大,比如自己的代码也许对自我要好来说很明显,但对客人则不然,那是无法幸免的,代码复审会让更加多个人有空子提议一蹴而就的提出,然后考虑是或不是可以通过重构来轻松的兑现它们。

留空白

  • 指出利用tabs
    而不是接纳空格,tabs缩进使用4个空格,确保在Xcode偏好设置来安装。
  • 文件截至时留一行空白
  • 用丰硕的空行把代码分割为客体的逻辑块,而不是卓殊紧凑
  • 无须在一行代码结尾处留空格
  • 更不用在空行(\n)中行使缩进(\t)

2.1 项目目录结构

项目标目录结构是支付中最基础的,但也是很重点的,清晰的目录结构可以令人一眼就看懂该类型的作业及作用,目录结构也能感应一个开发者的经验及架构水平。项目目录结构相比较正常的有三种,第一种是依照工作分类,第三种是坚守模块分类。当然具体还得依据具体的政工须要来做,适合自己的才是最好的。

那里有一篇关于项目目录结构的稿子,有趣味的童鞋可以读下:iOS
项目标目录结构能来看你的开发经历

胖 Model 的问题

上文精简 ViewController 把代码都投入到 Model 里去,所以会造成胖 Model
的题材。对此我的明白是,除了优化外,代码的总量是确定的,一方的凝练必然会促成一方的充实,而
Model 在此地是用来帮 ViewController 处理工作逻辑的,也就是说胖 Model
包括了一些弱业务逻辑。胖 Model 要达标的目标是,Controller从胖 Model
那里获得数码之后,不用额外做操作依旧一旦做十分少的操作,就可以将数据直接运用在
View 上,从那一点上看胖 Model 也是可以承受的。

2.5 代码规范

有关代码规范,每个程序员听从的代码规范多多少少都会有点分歧(比如如曾几何时候该空格,常量变量的命名方式等等),往日听一前辈说过,尽量遵从这些“约定俗成”的代码规范,其余在编码时,要有限辅助自己的代码规范始终一致,别给人一种你写的代码是几人共写的错觉。

  • 命名规范
    iOS
    命名首要注意多个地点,第一是可读性高,外人一看那一个名字就领会它的意义及功能;第二是谨防命名争论,命名时应坚守驼峰式命名法则,其它要加前缀,比如常量命名一般会在前头加上字母
    k。

  • 编码规范
    关于编码规范有无数细节须求留意,比如函数方法一般无法过长;比如实例变量的修饰符要注意;再比如说尽可能确保
    .h 文件精简,API
    尽量写在完成公文里……编码时还有其余一些应当注意的,比如写
    delegate 的时候类型应该为
    weak,以幸免循环引用;再比如说经典的圆角问题,过多的使用
    layer.masksToBounds
    对系统的开发分外大,会使页面变的卡顿等等……那几个编码细节有为数不少亟待专注,就不一一列举了。

  • 写注释
    写注释写注释写注释,首要的政工说一回。注释可以协助其余同事更好的知情您写的代码,还便宜温馨随后的阅读。

代码规范地点,那里也引进一篇不错的小说:iOS开发-代码细节优化(长时间更新)

再安利一本书,《编写高质地 iOS 与 OS X 代码的 52
个有效方法》,那本书对编码时应注意的底细写的很完善,往日读过五回,过几天会再读一遍,并记下。

布局规范

前段时间和一道事一起重构了多少个APP,正好想写一些重构心得,前几天又在虎扑上来看一长辈推荐《重构》那本书,据说是程序员的必读书籍,于是就概括的读了三遍,对重构有了更深层次的认识了。那里结合
iOS 项目标重构,谈谈与重构相关的题目,做一下笔录及享受。

最后

实际上总计起来就三点,尽量确保:

  • Controller 里的代码尽可能的少
  • Model 的功能尽可能的总体
  • View 尽可能独立

就能构建一个简单保证,便于协同的门类。

正文只是在项目重构中总计的有的相比根本的点,并不意味着都是最优解。而自我在类型的架构和代码的协会上经历尚浅,若本文有怎样错误可能有更好的点子请直接提出,欢迎沟通座谈。

1.2 为啥重构?

  • 重构可以帮您一向卓绝的控制自己的代码,它可以用来以下多少个目的:

    • 重构创新软件设计
      要是没有重构,程序的规划会日渐堕落变质。当大千世界只为长期目的,或是在一齐精通全部统筹从前,就贸然修改代码,程序将逐级失去自己的结构,程序员越来越难通过阅读源码而知晓原来的筹划。
      做到同样件业务,设计不良的先后往往需求更多代码,那日常是因为代码在分化的地方使用完全相同的言辞做相同的业务。由此改进设计的一个生死攸关取向就是扫除重复代码。

    • 重构使软件更易于领会
      书的先头有如此一句话:“任何一个傻子都能写出计算机可以领悟的代码,唯有写出人类不难精晓的代码,才是美好的程序员。”而重构可以使代码结构更清楚,使代码更易于被清楚。

    • 重构协理找到 bug
      对代码进行重构,可以深刻精晓代码的作为,并方便地把新的了然反馈回来,在重构的还要,大家得以窥见某些代码逻辑写的不谨慎或有问题。

    • 重构升高编程速度
      良好设计师维持软件开发速度的有史以来,重构可以帮你更神速地开发软件,因为它阻挡系统腐败变质,它如故仍可以加强规划质料。

代码分块

在函数分组和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

2.2 业务与 UI

那边不探究 MVC 架构与 MVVM
架构,关于架构方式之间的争辩有许多,个人比较赞同一个理念:绝不局限于
MVC、MVVM、MVP
等等一些架构方式,万变不离其宗,真正适用于项目标架构才是最好的架构。
刚接班的旧项目在规划初期以及支付进度中,没有进行客观的安插性,以至于有的控制器过于臃肿,代码量很多都是领先了
1000 行,有的竟是当先了 1500
行,而且写的很乱。重构的指标,就是增强代码的可读性以及福利将来的掩护,我那边按照MVC 的架构形式,将 UI
部分进行抽离,将工具代码(比如总计球面两点之间的离开)举办包装,并置于了有关的工具类中,又对控制器中的冗余代码举行了整理,使得控制器中的代码收缩至在此以前的三分之一以下。分享一张
cocoa 上的 MVC 架构图:

MVC 架构

AutoLayout

老项目是纯 Frame 布局,代码里有一大堆 Magic
Number,一大堆屏幕尺寸判断,而这个导致了花色里有过多的布局代码,对于刚上手项目标人来说也不太简单看懂。所以本次重构全部采取AutoLayout 布局,屏弃老品种里的纯 Frame 布局方式,精简代码。

二、结合 iOS 项目重构心得

品类层级细分

背景

第一说说背景,也就是为啥要重构,因为重构是急需资本的,一不小心修改错了,就会让原来完好的出品出各个问题,所以先统计下怎么,首若是以下三个问题:

  • 1.尚未统一的代码风格
    以此就相比悲伤了,因为历史的原由,或者说那些项目初期就没有代码规范,在接手项方今,代码风格就这么些自由、天马行空。在此期间我重构了一局部,但仍有半数以上不专业的代码。
  • 2.臃肿的 ViewController
    本条好明白,一个类几千行代码,应该的不应有的都挤在一齐。
  • 3.麻烦通晓的逻辑代码
    作业逻辑代码混乱不堪,看的感冒,还不敢乱删。
  • 4.混乱的类调用
    没有显明一个类该做哪些,全都堆在一块儿。

追求代码质料是一个绝妙程序员对团结的必要,所以趁这一个空子,决定把全体项目重构五遍。

前言

近日合作社的门类要翻新具有界面的 UI
风格,趁此机会正好把品种重构两回,本文主要记录重构时的有的选拔和化解的题目。

单元测试

老项目是不写测试代码的,也尚无写单元测试的标准化。想想一个类堆砌几千行代码,想写也不佳入手,但既然重构了,单元测试也得补上。
单元测试对于当前的话,就是为了有利于测试一些作用是或不是健康运作,还有调试接口是或不是能正常使用。
偶然你也许是为着测试某一个网络接口,然后每趟都再一次起动并且通过无数操作之后才测试到了要命网络接口,即使采纳了单元测试,就足以直接测试那一个格局,相对方便广大。
譬如由于修改较多,想测试一下享受成效是或不是健康,那时候就有用了。或者直接看有的接口重临的数量也会要命直观,不用启动全套工程。

精简 ViewController

这一片段自己认为是本次重构的关键性,也是此次重构的要紧指标所在,精简
ViewController 里的代码,解决老项目中 Massive ViewController 的题目。
第一办事分为以下几步:

  • 1.保留最重大的职务,拆分别的不主要的义务。
  • 2.拆分后的模块要尽量提升可复用性,尽量做到DRY
  • 3.增高拆分模块后的抽象度

代码块缩进

(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
}

物理层级

上文确认了品种架构是以 MVC 为主,所以这边推荐使用 MVC +
按工作划分项目层级的章程。具体的如下图:

图片 1

方方面面项目首要分为4个文件夹,分别是:

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

而其中 Classes 目录下,又细分如下图:

图片 2

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

命名

应用可读的驼峰命名法去给类、方法、变量命名。
常量应该利用驼峰式命名规则,所有的单词首字母大写和添加与类名有关的前缀。

合并的代码风格

无规矩不成方圆,在老项目里由于流程的缺失和开发人士的交替,一贯未曾一个合并的编码规范。而在三人支付时,保持统一的编码规范是很有必不可少的,那样简单保持代码一致性和
Code Review。所以确定了架构之后,接着就是确定编码规范。
下边是编码规范里有些内需留意的点:

相关文章