如何做一个合格的 iOS Team Leader

作者：项望烽，毕业于浙江大学，目前是网易云信 iOS 端研发负责人。

引言

担任项目的iOS Team Leader也有一年了，从被管理的程序员到管理程序员的Team Leader的转变，权责发生了明显变化，工作是烦恼的不再是具体某个功能、界面的实现，而是如何在现有代码的基础上做渐进式的改进，创造出比较合适规范和框架，使得组内成员更快更好地完成任务。通过自我学习和总结，也整理了些心得，希望能与同行共同学习和探讨。

合适的“战友”胜过任何牛逼的方法论

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

计算机界有句名言：计算机相关的所有问题都可以通过增加一个额外的抽象层来解决。但是软件开发却不是这样：增加层(人手)在一定程度上可以加快开发进度，当过了某个阈值后其效果就显得不是那么明显，甚至会起反效果。对于一个项目而言需要的往往不是更多的成员，而是适量的合适成员。每一个人因为不同的教育背景，从业背景，项目经历(技术选型，学习经历，项目管理)对程序开发都会有不同的理解和思维模式。反应在业务上就是各种各样的代码风格。举例来说：有些人恨不得把所有单一功能都一一独立出来封装成类，而有些人却喜欢一个大类洋洋洒洒写上上千行。大部分情况下我都是倾向于前者，但是就像我时常说的那样：It depends。不仅仅是软件开发，几乎所有的事到最终都会归结到一个统一的问题上：怎样才是一个度？

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

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

统一步调——规范很重要

大家都理解软件开发需要合适的规范：代码规范，程序规范，流程规范等等，以此来减少意外的出现：最少惊讶原则。但在实际执行中却会碰到各种情况，其中最大的问题是：怎么鉴别哪些规范是需要强制执行，哪些规范是推荐执行。规范的强制执行带来的是代码的可读性提升和二义性减少，而坏处也是显而易见的：对于大部分有想法的程序员而言这种规定太死板，容易引起抵触心理，产生不安定因素。这种情况常见于各种标准的外包公司。而如果大部分的规范设定为推荐执行，在没有良好的引导下，规范容易被忽视。 网上有很多关于ObjC的代码规范，比如苹果自家的规范和《Google Objective-C Style Guide》等。这些规范一般只有两种分级:推荐和不推荐。而我更推荐把代码规范分成五个等级：强制要求，强烈推荐(但不强制)，良好，可接受和不可接受。以下仅举部分例子加以说明。

1符合苹果规范的命名方式

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

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

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

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

2良好的代码和工程结构

★ 为整个工程创建worksapce。

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

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

• Core：工程内一些通用的机制实现类：统一的任务管理，模块管理，服务管理。
• General：公用类和方法，包括工程内ViewController,UITableViewCell基类(Base)，公用Category(Category)，公用UI组件(CustomUI)，公用辅助方法(Helper)和宏定义(Marco)。
• Model：公用数据模型
• Sections：不同程序单元。如登录，设置等等。其下又可以按照功能分成不同的子目录：当前单元使用的自定义UI组件，管理类，数据模型和ViewController等等。
• Vendors：第三方库。
  

提炼框架——继承既有的成果

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

1定义清晰的层次结构

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

★ 横向模块一般依赖于业务需求，常被定义成各种Service或Manager。一种好的做法是有个统一的Service管理器负责相应Serivce的加载，卸载，监听和分发App级别的通知给相应Service，如前后台切换，收到内存警告等。这样做一方面容易实现上面说的模块的可插拔化，另一方面也保证了公用特性处理的一致性。在这方面微信就做得不错，基本所有的模块都是从MMService继承而来，由MMServiceCenter进行管理。当然从dump出来的头文件也可以发现一些管理上的紊乱，比如一些ViewController都是继承自MMService。

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

• 展现层(Presentation layer)，负责管理UI和UIViewController；
• 逻辑层(Business/Service Layer)，负责逻辑数据的定义和转发，起到承上启下的作用；
• 数据访问层(Data Access Layer)，负责具体API构造，网络请求，数据持久化等。
  

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

2遵守SOLID原则和慎用各种设计模式

这是个老生常谈的话题了，并不是iOS开发独有，展开讲可以讲上几天几夜，不赘述。

3定义自己的UI基类：UIView，UIViewController，UITableviewCell

这一点的好处不言而喻，所有的子View，Controller，Cell都能够很方便的继承基类的共有的行为，样式。但也会引进很大的管理风险：组内成员总会经不起诱惑往基类塞各种并不普适的特性，引起基类权责的无限膨胀。大基类不仅增加组内成员对代码的理解难度，同时也增加出现问题时的排查难度。从这方面讲，微信的UIViewController基类设计就极端失败：MMUIViewController这个类光头文件就有上百行（编者注：这算是云信开发人员鄙视同行微信吗？哈哈）。

4提供方便好用的工具类

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

5好的范例

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

附录：更多感悟和思考

《一个微信实习生自述：我眼中的微信开发团队》
《微信程序员创业总结：如何提高Android开发效率》
《如何做一个合格的 iOS Team Leader》
《程序员中年危机：拿什么拯救你，我的三十五岁》
《一个魔都程序员的3年：从程序员到CTO的历练》
《为什么说即时通讯社交APP创业就是一个坑？》
《致我们再也回不去的 Github ...》
《一名90后二流大学程序员的自述：我是如何从“菜鸟”到“辣鸡”的》
《一个魔都程序员的3年：从程序员到CTO的历练》
《选择比努力更重要：我是如何从流水线工人到程序员的？》
《程序员的抉择：必须离开帝都——因为除了工作机会，还有什么值得留恋？》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》
《程序员神级跳槽攻略：什么时候该跳？做什么准备？到哪里找工作？》
《感悟分享：在腾讯的八年，我的成长之路和职业思考》
《调皮的程序员：Linux之父雕刻在Linux内核中的故事》
《迷茫中前行：一个专科渣渣菜鸟的编程入门感悟》
《盘点和反思在微信的阴影下艰难求生的移动端IM应用》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？
《机会不给无准备的人：一个Android程序员屡战屡败的悲惨校招经历》
《笑中带泪的码农往事：入职三天被开，公司给100块叫我走人，有我惨？》
《一个野生程序员的真实自述：我是如何从数学专业学渣入坑程序员的》
《鹅厂7年终有离开之日，记离职鹅厂最后30天的真实心路历程》
《4年前端、2年CTO：一个非科班程序员的真实奋斗史》

全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

（原文链接：点此查看）

我帮整理了一下排版，且增加作者的说明的原文链接，尊重原创。

这兄弟挺有想法，文章写的不错。
它的另外两篇文章在 52im.net 也可以找到：
http://www.52im.net/thread-133-1-1.html
http://www.52im.net/thread-134-1-1.html

引用：JackJiang 发表于 2016-03-09 11:15
我帮整理了一下排版，且增加作者的说明的原文链接，尊重原创。

这兄弟挺有想法，文章写的不错。

谢谢Jack，写的还可以，顺手转过来了，让大家也看看。他是网易云信的，都是做IM的同行嘛，哈哈

感谢分享，虽然有那么一点点年少轻狂的味道...

不错，加油

不错