自从做Team Leader之后,身上权责发生了变化,于是让我烦恼的不再是具体某个功能,某个界面的实现,而是如何在现有代码的基础上做渐进式的改进,创造出比较合适规范和框架,使得组内成员更快更好地完成任务。一年下来,颇有点想法,于是啰嗦几句关于iOS App开发的那些事。
首先明确一点,合适的人是指纯技术团队的建设。一支战斗力再强的技术团队,面对一个朝三暮四,分分钟推翻自己原有想法的产品经理/项目经理,再好的戏也唱不出来。花几个月加班加点做项目,还没发布,直接推翻重做,这时候你就得去楼下ATM机看看卡内余额了:余额够了,收拾收拾好找下一家了。
计算机界有句名言:计算机相关的所有问题都可以通过增加一个额外的抽象层来解决。但是软件开发却不是这样:增加层(人手)在一定程度上可以加快开发进度,当过了某个阈值后其效果就显得不是那么明显,甚至会起反效果。对于一个项目而言需要的往往不是更多的成员,而是适量的合适成员。每一个人因为不同的教育背景,从业背景,项目经历(技术选型,学习经历,项目管理)对程序开发都会有不同的理解和思维模式。反应在业务上就是各种各样的代码风格。举例来说:有些人恨不得把所有单一功能都一一独立出来封装成类,而有些人却喜欢一个大类洋洋洒洒写上上千行。大部分情况下我都是倾向于前者,但是就像我时常吐槽的那样:It depends。不仅仅是软件开发,几乎所有的事到最终都会归结到一个统一的问题上:怎样才是一个度?一群理念相去甚远的人在一起工作是件异常痛苦的事:相当一部分的时间会浪费在解释,争论和排遣由此带来的沮丧和愤怒上。古人语:道不同,不相为谋。但到了真正的工作中却不能如此随性,缺乏足够动力的老人,能力出众的技术骨干,干劲十足却缺乏经验的新人都需要互相体谅,学习和磨合。所以大部分创业公司的技术团队因为理念相近,往往效率会足够高,而大公司内的开发小组却永远无法达到那样的效率,更需要相应的规范和程序框架。
得出上面这个结论的另一个理由是我对人的可塑造性是持悲观态度的:多数人并没有跳出自己思维局限性的意愿,动力和能力。少数人在没有任何外界压力的情况下仍会不断总结学习进步(主动学习型),而其余的人要么没有任何意愿,关心的只是完成任务和拿到工资而已,要么想要进步而不得法。而你的团队不可能全由主动学习型的成员组成,这时候规范和程序框架的引入才能够让各种类型的人更好的合作。
大家都理解软件开发需要合适的规范:代码规范,程序规范,流程规范等等,以此来减少意外的出现:最少惊讶原则。但在实际执行中却会碰到各种情况,其中最大的问题是:怎么鉴别哪些规范是需要强制执行,哪些规范是推荐执行。规范的强制执行带来的是代码的可读性提升和二义性减少,而坏处也是显而易见的:对于大部分有想法的程序员而言这种规定太死板,容易引起抵触心理,产生不安定因素。这种情况常见于各种标准的外包公司。而如果大部分的规范设定为推荐执行,在没有良好的引导下,规范容易被忽视。 网上有很多关于ObjC的代码规范,比如苹果自家的规范和《Google Objective-C Style Guide》等。这些规范一般只有两种分级:推荐和不推荐。而我更推荐把代码规范分成五个等级:强制要求,强烈推荐(但不强制),良好,可接受和不可接受。以下仅举部分例子加以说明。
Core:工程内一些通用的机制实现类:统一的任务管理,模块管理,服务管理。
General:公用类和方法,包括工程内ViewController,UITableViewCell基类(Base),公用Category(Category),公用UI组件(CustomUI),公用辅助方法(Helper)和宏定义(Marco)。
Model:公用数据模型
Sections:不同程序单元。如登录,设置等等。其下又可以按照功能分成不同的子目录:当前单元使用的自定义UI组件,管理类,数据模型和ViewController等等。
Vendors:第三方库。
一个合适的框架不是银弹,在我看来框架要解决的问题从来不是:有了框架之后,工程就能无比正确地进行下去。好的框架能够做到的事仅仅只是:降低通用问题的复杂度和减少发生错误的可能性。个人认为一个良好iOS App框架应该是有如下特点:
好的范例。在前几年使用C++的那段暗无天日的日子里,我常想的一个问题是:如何在API层面去限制和规避一些错误。比如往线程池里面扔的task必须是堆上分配的对象,那么如何去强制传入的指针指向的是堆地址而不是栈地址呢?这种傻问题大部分情况下是无解的,有时候有解却是个异常别扭的解。而现在我更相信破窗理论所提供的可能性:做好示范,接下来的一切都会水到渠成。