iOS架构师之路:工程文件组织结构设计

开场

编程是如出一辙门艺术在,不允?嘿嘿,那不用特别跟你翻两只白。没关系,你肯定会同意就句话:艺术品的一个及其主要且务必有特征就是是她都是出于艺术家创作出的O(∩_∩)O~。方才小生我是挑起你玩的,讲真艺术品是由于艺术家创作是从未外问题的,当然其实艺术品还有一个表征就是是她把要的细节发挥到极致致。所以,作为ios架构师,不加大了任何一个可以升级项目质量、效率、健壮性等等的技术手段,也就是是分内事了。也许是无敷有技术含量,,发现国内外鲜有关于工程文件组织结构设计的文章。但是自本人顶了之几乎独品种来拘禁,一个吓之工文件组织结构会起源头上升级工程师的支付效率,提升型之健壮性和而扩展性,而自己吧领略的观过一些类别为糟糕之文件目录设计,导致代码管理暨类型提高历程会带动的题材。

一个吓的工程文件组织结构设计的助益

1.工文件分类明确,文件容易寻找

2.索引功能定义清晰,工程师能随随便便理解当哪创建新文件,尤其是当组织有上秤座的工程师经常

3.工程及磁盘文件结构清晰,代码维护好

4.目录粒度足够精细,减少项目依赖关系与长模块的可移植性

……

有关MVC架构的以工程中简单栽体现形式

1.发成千上万门类是直以工程里创建Controllers、Views、Models这样的目结构…这样分类
2.遵循
Feature来分,每个Feature里面有Controllers、Views、Models…这样分类

ios开发分工有点儿种植,一种植是子开发,第一种形式适合分层开发,一栽是分feature开发,第二种植形式适合分feature开发。分层开发通常是有人负责DAO层(数据存取)开发,有人担控制器和view层的出,但是当API尚未形成,而且Dao层同事对事情层关注不够,DAO层开发的底同事就了需要借助自己之想象力去规划数据存取的接口,而往往就跟事实上API提供的接口存在巨大的落差,从而致使分层开发之各层都见面做出大量代码重构。所以分feature开发是豪门比较容易接受的一律种开发方式。

用自己的提议:是以第二种植MVC组织形式,如果你下MVVM或者其它,也可参考这思路。其实首先种形式还有一个题目,比如你若摸索ControllerA的TableView用到之cellB类,你还要去Views里面一个个搜索,太痛了,就算search也或苦毕竟不能够所呈现就所得。而分feature则对于负责这个feature的支付工程师找到关于文件则容易之大半矣。

关于Helper与Utility文件夹

本身看了无数品种,包括团结与了之有色还是没Helper,要么没Utility文件夹,而是以她们混合于齐,傻傻分不清楚。
本身之提议:尽量细粒度化项目目录结构,在品种里分别提供helper目录和utility目录给开发者使用。与业务无关,具有对象性质,提供支撑力量的代码放到Helper,比如创建一个自定义对象的包裹。如果只是属于函数或算法,不是目标又不少地方会就此到,就放到Utility,比如排序/加密算法。

关于Common文件夹

此在大神casa的章《iOS应用架构谈
开篇》已经出鲜明的象征,在外的稿子中他提议在工程成功不要产生Common文件夹。我一直以来可能还践行细粒度的目录结构划分方式,所以由我顶架构的型还尚未过common文件夹。我呢比认同casa的眼光,不仅仅是针对common文件夹,其实前面提到的helper和utility文件夹之所以拆分开也是坐梦想能够细致粒度拆分模块,减少横向依赖。

Common的功利只来一个,就是最初特别省事儿。然而其的弊病比好处要多尽多。

Common不仅仅是一个文件夹,它为会见是一个Pod。不管是啊,在Common里面颇容易形成错综复杂的略微模块依赖,在模块成长历程中,会纵容工程师不在意依赖之管住,乃至于将来只要只要以模块拆分出去,会老的艰难。
Common本身以及细粒度模块设计之沉思背道而驰,属于同一种不确切的偷懒手段,在未来政工拓张会化阻挡。
若设置了Common,就当为地狱之家打开了一个小缝,每次业务迭代都见面有一些请勿极端好分类的事物放入Common,这就是受保安Common的人头带了大酷的工作量,而且这些工作量全都是体力活,非常容易出错。

自家提议在列蒙未使Common文件夹。这样工程师于创建有共有文件,就必须依照他们的职责将她们分至不同模块里去,而不是偷懒,扔到common里,这样做虽然前期很困难,但是对后期维护、扩展、移植将拉动巨大的补。你见面发现路之可维护性大大提高,模块升级后如果举行的同步工作挺轻松,解放了大苦逼的Common维护者,更多的辰可就此当重复本质的开工作达到。这符合自己移植强调的细粒度模块划分的架思想。

至于Xcode的公文夹如何创造

Xcode中组(Group) 和 文件夹引用(Folder Reference)的界别

方说了一些关于目录结构设计事情,现在说说 Xcode
的文书夹。我看了许多列,我以为相当一些底种之公文夹管理不客观。在Xcode中
项目之文书夹来 Group 和 Folder Reference 之分。它们的分别在 Xcode
Groups vs. Folder
References
这篇稿子里发生详尽的叙述。

组和文件夹引用

Group 的缺陷如下:

1)Xcode 会为每个文件创建一个 reference,存储于 project.pbxproj
文件被,当起多独 target 时,每个文件之 reference
会被复制多单,这就算见面大大加 project.pbxproj
文件之尺寸及复杂度,这对于代码版本管理来是个头疼的题材,尤其是遇上 merge
conflict 的下。
2)项目被 Group
的布局和磁盘上的文件价的结构得以视为没有底关系之,在磁盘上的一个文书在一个某文件夹着,但是以
Xcode 的品种结构被,它或许于另 Group
中,这样想要错过摸对应的文本就常为人口稀晕。
3)如果您于 Xcode 之外直接去 Finder 里活动类文件及不同之目时,那么当
Xcode 中针对之文件的 reference 就见面坏掉。
Group 的独到之处如下:

1)你可选取磁盘上的文件上加到项目被,不思要之莫弥加就是执行了。
2)对不同的 target 对应之文书能够更好地保管,比如,你可以择针对性一个
target 排除有一个文书。
3)当 build 的下,Xcode 会把所有的 Group 下之公文都加大至 bundle
的一等目录,所以你调用文件时无需制定它的具体位置,比如,你不用如此
[UIImage imageNamed:@”Images/Icons/Go”]; ,这之所以这样虽好 [UIImage
imageNamed:@”Go”];,但是这虽象征当合项目受到,你无能够发同名的公文了。
Folder Reference 的发这些亮点:

1)Xcode 只存储 folder 的 reference,这个 folder 下所有的文件和
subfolder
都见面活动添加至品种被去。这会使项目文件再次有些更简便,代码版本管理时,产生
merge conflict 的可能就是再也少。
2)如果您以文件系统中一直指向 folder 下的文件进行改动、移动还是去,Xcode
会自动更新对应之 folder reference
来反应这些改动,这样管理型文件也再度简便易行。
3)项目之构造与 folder 在磁盘的组织是相同的,这样虽未会见晕菜了。
4)由于在不同的 folder 路径,你就无待操心文件重名问题了,因为在
build 的时刻,文件夹结构吧会于安放 bundle 中失。
Folder Reference 的出这些老毛病:

1)对两样之 target 的治本是独不幸,因为一个 folder
下之代码或文件,要么全同或全不要。当然,如果您能为不同的 target
去立不同之 Folder Reference,这看起也远非什么坏的。
2)对 folder 下的文本无法藏身,磁盘上要这个 folder
下有此文件,那么当项目组织面临便会盼其。
3)在加载文件资源的时刻,你必制定全路线。也就是说,你得如此:[UIImage
imageNamed:@”Images/Icons/Go”];。
4)存储于 Folder Reference 中的图形以 Interface Builder
中动用时见面遇见各种问题。
以骨子里运用中,使用 Group 要多得几近。

Xcode 项目结构和磁盘金沙银河注册送38文件结构的相应

面说了 Group 和 Folder Reference
各自的利弊,在档次遭到,我习惯及吗是休使 Folder Reference,只所以
Group。在 Xcode 项目被创造 Group 的法有半点栽:

1)第一栽方式:创建时用先在磁盘上开创对应之文书夹,再将文件夹拖进
Xcode 项目蒙对应之职位,并选 Create groups for any added
folders。这样创建的 Group 会对诺在磁盘上之 Folder。

2)第二种植艺术:直接当 Xcode 项目被创造 Group。

本着照 Xcode 项目之 MyProject.xcodeproj/project.pbxproj 文件可以见到相应着
Folder 的 Group 和一直开立的 Group 的分别就是在于前者是用 path
属性去记录,后者是为此 name 属性去记录。如下,Helper 是一个反常应 Folder
的 Group,Resource 是一个应和 Folder 的
Group。通过各个结点的父子关系以及 path 属性,Xcode 就可知管住好每个文件的
Reference。

//MyProject.xcodeproj/project.pbxproj

45E59EDF18BBA92C00251797 /* Helper */ = {
     isa = PBXGroup;
     children = (
          452183D3195AA18F00679F14 /* CXTaskControlService.h */,
          452183D4195AA18F00679F14 /* CXTaskControlService.m */,
     );
     name = Helper;
     sourceTree = "<group>";
};
45E59EE318BC2B4100251797 /* Resource */ = {
     isa = PBXGroup;
     children = (
          45E59EE418BC2B4100251797 /* Image */,
          45C97CA91900260A0020C517 /* Sound */,
     );
     path = Resource;
     sourceTree = "<group>";
};

对于第一种方式:

好处:这样磁盘上之布局以及 Xcode 中的种类结构即是逐一对应之。让 Xcode
的目录结构能跟磁盘文件之布局保持一致,这样被在寻代码文件之时刻能够重新清楚。

坏处:创建与管制代码文件时将麻烦一些。当你在 Xcode
项目面临管一个文本于一个索引拖动到另外一个目录中不时,它以 Xcode
中显示的目录路径改变了,但是她于磁盘上之情理位置并不曾出转移,这虽会造成杂乱。所以,为了保持对诺提到,当您一旦改文件的目录时,你得手动到
Finder 文件夹着失去运动文件,再在 Xcode
项目遭到失去相应的文本引用再又长到新的目下。这还要带来了另外一个题材,就是
git
对文本之本管理信息会受坏,你或许无法观这个文件前的版本了,这个代价而即便老了。所以,如果如采用版本管理,就要好好考虑这个因素了。

对于第二种方式:

好处:直接在 Xcode
中管理类,添加、删除、移动还坏便利。采用版本管理时,代码文件之版本信息不会见以运动如果丢掉。

坏处:Xcode 中之项目布局以及磁盘上的结构不克挨个对应。
基于上面的对照,

自身的建议:对于固定的不过复用代码可以用第一栽方法,因为也不见面时不时活动。复用时,挪动起来可以操作;对于那个的目录结构,比如一级目录:Utilities、Helpers、Features、Resource
等目录可以使用第一种植方法。其他的状况均运用第二栽艺术就执行了。

本身今天路的工程结构设计样例

废话不多说,最后吃大家举一个自家现在种一般采取工程文件设计布局的事例吧

1.主目录结构
-ProjectDemo
    --Features         //模块。包含各个模块的Model,View,Controller,Manager
    --categories            //类目。包含各种类的分类
    --Frameworks        //系统框架。包含导入的系统的框架
    --Helpers           //帮助类。包含网络,数据库,归档,定位等操作类的封装和实现
    --Utilites       //工具类,一些非对象的,而是类方法调用的类
    --Vendors           //第三方库。部分需要修改或者不支持cocoapod的第三方的框架引入
    --Config                //配置。包含宏定义文件,全局配置文件,全局常量文件,颜色配置文件
    --Resources         //资源。包含plist,image,html,bundle,Localizable.strings等
    --AppEntry          //程序入口。包含AppDelegate,main.c,info.plist
-PAHealthTests
-PAHealthUITests
-Products           // 系统自动生成的.app所在文件夹
-Pods                   // 采用 CocoaPods 管理的第三方库。

2.模块目录结构
-- Features         
    ---Base             //MVC的基类或者通用类
        ----Models      //数据模型
        ----Views       //视图
        ----Controllers //控制器
        ----Manager     //store层的数据管理类
    ---Home
        ----Models
        ----Views
        ----Controllers
        ----Manager
    ---UserCenter
        ----Models
        ----Views
        ----Controllers
        ----Manager
    ---UserEntry
        ----Models
        ----Views
        ----Controllers
        ----Manager

    ---Payment
        ----Models
        ----Views
        ----Controllers
        ----Manager
    …

参照文章

iOS项目之目结构
iOS应用架构谈
开篇

相关文章