自从做Team Leader之后，身上权责发生了变化，于是让我烦恼的不再是具体某个功能，某个界面的实现，而是如何在现有代码的基础上做渐进式的改进，创造出比较合适规范和框架，使得组内成员更快更好地完成任务。一年下来，颇有点想法，于是啰嗦几句关于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必须是堆上分配的对象，那么如何去强制传入的指针指向的是堆地址而不是栈地址呢？这种傻问题大部分情况下是无解的，有时候有解却是个异常别扭的解。而现在我更相信破窗理论所提供的可能性：做好示范，接下来的一切都会水到渠成。