成为 Team Leader 后我最关心的那些事
推荐序
老有人问我 iOS 开发如何提高，今天收到一个来自网易的朋友投稿，分享他在成为 iOS 项目负责人之后面临的问题。文章中分享的如何招人，如何确定规范，如何组织好代码结构，这些其实都是一个 iOS 开发者提高过程中需要思考的问题。
另外，网易的资深 iOS 开发者最近都在自己的网易云课堂平台上开设 iOS 相关课程，如果感兴趣可以参见文末的介绍。
感谢项望烽的投稿和授权。
文 / 项望烽（网易移动端技术专家）
本文适合有1-3年工作经验的iOS开发从业者阅读
成为 Team Leader 之后，让我烦恼的不再是具体某个功能，某个界面的实现，而是如何在现有代码的基础上做渐进式的改进，创造出比较合适规范和框架，使得组内成员更快更好地完成任务。
对此颇有点想法，想与大家谈谈关于App开发的那些事。
选择合适的人
首先明确一点，合适的人是指纯技术团队的建设。一支战斗力再强的技术团队，面对一个朝三暮四、分分钟推翻自己原有想法的产品经理，再好的戏也唱不出来。花几个月加班加点做项目，还没发布，直接推翻重做，这时候你就得去楼下 ATM 机看看卡内余额了：余额够了，收拾收拾好找下一家了。
对于一个项目而言，需要的不是更多成员，而是适量的合适成员。每一个人因为不同的教育背景、从业背景、项目经历对程序开发都会有不同的理解和思维模式，反应在业务上就是各种各样的代码风格。
举例来说：有些人恨不得把所有单一功能都一一独立出来封装成类，而有些人却喜欢一个大类洋洋洒洒写上上千行。一群理念相去甚远的人在一起工作是件异常痛苦的事：相当一部分的时间会浪费在解释、争论和排遣由此带来的沮丧和愤怒上。
古人语：道不同，不相为谋。但到了真正的工作中却不能如此随性，缺乏足够动力的老人，能力出众的技术骨干，干劲十足却缺乏经验的新人都需要互相体谅、学习和磨合。所以大部分创业公司的技术团队因为理念相近，往往效率会足够高，而大公司内的开发小组却永远无法达到那样的效率，更需要相应的规范和程序框架。
明确合适的规范
大家都理解软件开发需要合适的规范：代码规范，程序规范，流程规范等等，以此来减少意外的出现：最少惊讶原则。
但在实际执行中却会碰到各种情况，其中最大的问题是：怎么鉴别哪些规范是需要强制执行，哪些规范是推荐执行？规范的强制执行带来的是代码的可读性提升和二义性减少，而坏处也是显而易见的：对于大部分有想法的程序员而言这种规定太死板，容易引起抵触心理，产生不安定因素。这种情况常见于各种标准的外包公司。而如果大部分的规范设定为推荐执行，在没有良好的引导下，规范容易被忽视。
网上有很多关于 ObjC 的代码规范，比如苹果自家的规范和 《Google Objective-C Style Guide》。这些规范一般只有两种分级:推荐和不推荐。而我更推荐把代码规范分成五个等级：强制要求，强烈推荐(但不强制)，良好，可接受和不可接受。
以下仅举部分例子加以说明：
【符合苹果规范的命名方式】
√ 强烈要求——类名开头大写，方法和变量名以驼峰法命名。
√ 强烈推荐——类名使用至少三个字符做前缀，内部方法使用两个下划线做前缀。
√ 强烈推荐——无论使用 K&R Style 还是 Allman Style 都是可接受的范围，但是强烈推荐在一个文件内保持一种形式。
√ 强烈推荐——在保证代码可读性的基础上保持代码的简短和统一性：小类，小方法，统一的函数返回。
【良好的代码/工程结构】
√ 为整个工程创建 workspace。
√ 按照权责分门别类存放资源文件：每种类型的资源存放于独立的目录下：图片，声音，配置文件等等。而图片又可以按照类型分别存放在不同的子目录下：全局类型，背景图，logo，登录等等。
√ 合理的代码结构。推荐如下的工程目录结构：
Core：工程内一些通用的机制实现类：统一的任务管理，模块管理，服务管理。
General：公用类和方法，包括工程内 ViewController, UITableViewCell 基类(Base)，公用Category，公用 UI 组件(CustomUI)，公用辅助方法(Helper)和宏定义(Macro)。
Model：公用数据模型
Sections：不同程序单元。如登录，设置等等。其下又可以按照功能分成不同的子目录：当前单元使用的自定义UI组件，管理类，数据模型和ViewController 等等。
Vendors：第三方库。
选择合适的框架
一个合适的框架不是银弹，在我看来框架要解决的问题从来不是：有了框架之后，工程就能无比正确地进行下去。好的框架能够做到的事仅仅只是：降低通用问题的复杂度和减少发生错误的可能性。个人认为一个良好 iOS App 框架应该是有如下特点：
√ 定义清晰的层次结构；
√ 遵守 SOLID 原则和慎用各种设计模式。这是个老生常谈的话题了，并不是 iOS 开发独有，展开讲可以讲上几天几夜，不赘述；
√ 定义自己的 UI 基类：UIView，UIViewController，UITableviewCell。这一点的好处不言而喻，所有的子 View，Controller，Cell 都能够很方便的继承基类的共有的行为，样式；
√ 提供方便好用的工具类。一些好用的工具类往往会成为框架重要的有机组成部分，方便快捷地解决局部问题，同时又不引入过多的复杂度；
√ 好的范例。在前几年使用 C++ 的那段暗无天日的日子里，我常想的一个问题是：如何在 API 层面去限制和规避一些错误。比如往线程池里面扔的 task 必须是堆上分配的对象，那么如何去强制传入的指针指向的是堆地址而不是栈地址呢？这种傻问题大部分情况下是无解的，有时候有解却是个异常别扭的解。而现在我更相信破窗理论所提供的可能性：做好示范，接下来的一切都会水到渠成。
看到这里，不知道你对自己的iOS开发经验是不是有了更多的感悟~