iOS App开发那些事：如何选择合适的人、规范和框架？

话大道理，笑话小说，小白兔的笑话，小学生笑话大全，开心小笑话，小学生幽默笑话，小明系列冷笑话，小白兔笑话，笑话小故事，小明冷笑话大全，经典小笑话

合适的人

首 先明确一点，合适的人是指纯技术团队的建设。一支战斗力再强的技术团队，面对一个朝三暮四，分分钟推翻自己原有想法的产品经理/项目经理，再好的戏也唱不 出来。花几个月加班加点做项目，还没发布，直接推翻重做，这时候你就得去楼下ATM机看看卡内余额了：余额够了，收拾收拾好找下一家了。 

计 算机界有句名言：计算机相关的所有问题都可以通过增加一个额外的抽象层来解决。但是软件开发却不是这样：增加层(人手)在一定程度上可以加快开发进度，当 过了某个阈值后其效果就显得不是那么明显，甚至会起反效果。对于一个项目而言需要的往往不是更多的成员，而是适量的合适成员。 

每一个人因为不同的教育背景，从业背景，项目经历(技术选型，学习经历，项目管理)对程序开发都会有不同的理解和思维模式。反应在业务上就是各种各样的代码风格。举例来说：有些人恨不得把所有单一功能都一一独立出来封装成类，而有些人却喜欢一个大类洋洋洒洒写上上千行。大部分情况下我都是倾向于前者，但是就像我时常吐槽的那样：It depends。不仅仅是软件开发，几乎所有的事到最终都会归结到一个统一的问题上：怎样才是一个度？ 

一群理念相去甚远的人在一起工作是件异常痛苦的事：相当一 部分的时间会浪费在解释，争论和排遣由此带来的沮丧和愤怒上。古人语：道不同，不相为谋。但到了真正的工作中却不能如此随性，缺乏足够动力的老人，能力出 众的技术骨干，干劲十足却缺乏经验的新人都需要互相体谅，学习和磨合。所以大部分的创业团队的技术团队因为理念相近，往往效率会足够高，而大公司内的开发 小组却永远无法达到那样的效率，更需要相应的规范和程序框架。 

得 出上面这个结论的另一个理由是我对人的可塑造性是持悲观态度的：多数人并没有跳出自己思维局限性的意愿，动力和能力。少数人在没有任何外界压力的情况下仍 会不断总结学习进步(主动学习型)，而其余的人要么没有任何意愿，关心的只是完成任务和拿到工资而已，要么想要进步而不得法。而你的团队不可能全由主动学 习型的成员组成，这时候规范和程序框架的引入才能够让各种类型的人更好的合作。 

合适的规范

大 家都理解软件开发需要合适的规范：代码规范，程序规范，流程规范等等，以此来减少意外的出现：最少惊讶原则。但在实际执行中却会碰到各种情况，其中最大的 问题是：怎么鉴别哪些规范是需要强制执行，那些规范是推荐执行。规范的强制执行带来的是代码的可读性提升和二义性减少，而坏处也是显而易见的：对于大部分 有想法的程序员而言这种规定太死板，容易引起抵触心理，产生不安定因素。这种情况常见于各种标准的外包公司。 

而 如果大部分的规范设定为推荐执行，在没有良好的引导下，规范容易被忽视。 网上有很多关于ObjC的代码规范，比如苹果自家的规范和《Google Objective-C Style Guide》等。这些规范一般只有两种分级:推荐和不推荐。而我更推荐把代码规范分成五个等级：强制要求，强烈推荐(但不强制)，良好，可接受和不可接 受。以下仅举部分例子加以说明。

符合苹果规范的命名方式

类 名开头大写，方法和变量名以驼峰法命名。强烈要求，这没有什么好说的，苹果系统类库和绝大多数的第三方开源库都是如此。但在部分苹果的sample中也看 到过用m做前缀表示类成员变量的写法，这些都是属于遗产代码的问题，仍旧是可接受范围，但是自己代码内部使用类似匈牙利的命名法就是不可接受。 

类名使用至少三个字符做前缀，内部方法使用两个下划线做前缀。强烈推荐。上面的做法可以最大程度避免和系统类库发生重名的情况：因为苹果宣称保留所有两位字符前缀的使用权，同时其内部方法命名以一个下划线做前缀。 

无论使用K&R Style还是Allman Style都是可接受的范围，但是强烈推荐在一个文件内保持一种形式。 

在 保证代码可读性的基础上保持代码的简短和统一性：小类，小方法，统一的函数返回。小类，小方法可以保证他人阅读时更方便地关注类逻辑，而不是具体细节，而 统一的函数返回可以减少意外错误和降低错误排查的难度。而保证代码的简短和不罗嗦也是很重要一点，经常会看到如下代码： > (count > 1) { return YES; } { return NO; } 真心无法直视。

良好的代码/工程结构

为整个工程创建worksapce。 

按照权责分门别类存放资源文件：每种类型的资源存放于独立的目录下：图片，声音，配置文件等等。而图片又可以按照类型分别存放在不同的子目录下：全局类型，背景图，logo，登录等等。

合理的代码结构。推荐如下的工程目录结构

Core：工程内一些通用的机制实现类：统一的任务管理，模块管理，服务管理。 

General：公用类和方法，包括工程内ViewController,UITableViewCell基类(Base)，公用Category(Category)，公用UI组件(CustomUI)，公用辅助方法(Helper)和宏定义(Marco)。 

Model：公用数据模型 

Sections：不同程序单元。如登录，设置等等。其下又可以按照功能分成不同的子目录：当前单元使用的自定义UI组件，管理类，数据模型和ViewController等等。 

Vendors：第三方库。

合适的框架

一个合适的框架不是银弹，在我看来框架要解决的问题从来不是：有了框架之后，工程就能无比正确地进行下去。好的框架能够做到的事仅仅只是：降低通用问题的复杂度和减少发生错误的可能性。个人认为一个良好iOS App框架应该是有如下特点： 

定义清晰的层次结构

展现层(Presentation layer)，负责管理UI和UIViewController 

逻辑层(Business/Service Layer)，负责逻辑数据的定义和转发，起到承上启下的作用。 

数据访问层(Data Access Layer)，负责具体API构造，网络请求，数据持久化等。

各 层根据业务逻辑的复杂性内部又会使用单层或者多层结构。以数据访问层为例，一般又可以细分为网络层，持久化层。而一般而言，展现层(UIView和 UIViewController)都是直接使用逻辑层提供的Model进行展现，但是某些场景下往往需要不同的Model有相同的界面展示(如我们的 App易信中，会话界面，收藏界面，问一问功能都需要进行图片的展现，但这三个模块下的Model定义并不一致)，这就需要增加额外的ViewModel 层用于粘合展现层和逻辑Model。 

横向上，各模块互相独立，仅通过有限的几个接口进行通讯。最理想的状态是除核心模块外，其他模块都是可拔插。纵向上，各层次间依赖关系清晰，基本不出现逆向依赖的情况。 

横向模块一般依赖于业务需求，常被定义成各种Service或Manager。一种好的做法是有个统一的Service管理器负责相应Serivce的加载，卸载，监听和分发App级别的通知给相应Service，如前后台切换，收到内存警告等。

这 样做一方面容易实现上面说的模块的可插拔化，另一方面也保证了公用特性处理的一致性。在这方面微信就做得不错，基本所有的模块都是从MMService继 承而来，由MMServiceCenter进行管理。当然从dump出来的头文件也可以发现一些管理上的紊乱，比如一些ViewController都是 继承自MMService。

纵向的层次划分基本各个App不会有太大区别，一般可以分为三个层次： 

遵守SOLID原则和慎用各种设计模式。这是个老生常谈的话题了，并不是iOS开发独有，展开讲可以讲上几天几夜，不赘述。 

定 义自己的UI基类：UIView，UIViewController，UITableviewCell。这一点的好处不言而喻，所有的子 View，Controller，Cell都能够很方便的继承基类的共有的行为，样式。但也会引进很大的管理风险：组内成员总会经不起诱惑往基类塞各种并 不普适的特性，引起基类权责的无限膨胀。大基类不仅增加组内成员对代码的理解难度，同时也增加出现问题时的排查难度。从这方面讲，微信的 UIViewController基类设计就极端失败：MMUIViewController。 

提 供方便好用的工具类。一些好用的工具类往往会成为框架重要的有机组成部分，方便快捷地解决局部问题，同时又不引入过多的复杂度。NSTimer的 retain cycle是个很容易掉去的坑，那么提供一个基于Block或者weak delegate的NSTimer的封装就是不错的选择。使用KVO容易发生add和remove的不配对调用，那么就引入 THObserversAndBinders或者FB的KVOContorller。某些核心模块需要被多个模块依赖时，引入类似XMPP的 GCDMulticastDelegate就能够方便地进行解耦。 

好 的范例。在前几年使用C++的那段暗无天日的日子里，我常想的一个问题是：如何在API层面去限制和规避一些错误。比如往线程池里面扔的task必须是堆 上分配的对象，那么如何去强制传入的指针指向的是堆地址而不是栈地址呢？这种傻问题大部分情况下是无解的，有时候有解却是个异常别扭的解。而现在我更相信 破窗理论所提供的可能性：做好示范，接下来的一切都会水到渠成。

（来自:IT江湖）