话大道理,笑话小说,小白兔的笑话,小学生笑话大全,开心小笑话,小学生幽默笑话,小明系列冷笑话,小白兔笑话,笑话小故事,小明冷笑话大全,经典小笑话
合适的人
首 先明确一点,合适的人是指纯技术团队的建设。一支战斗力再强的技术团队,面对一个朝三暮四,分分钟推翻自己原有想法的产品经理/项目经理,再好的戏也唱不 出来。花几个月加班加点做项目,还没发布,直接推翻重做,这时候你就得去楼下ATM机看看卡内余额了:余额够了,收拾收拾好找下一家了。
计 算机界有句名言:计算机相关的所有问题都可以通过增加一个额外的抽象层来解决。但是软件开发却不是这样:增加层(人手)在一定程度上可以加快开发进度,当 过了某个阈值后其效果就显得不是那么明显,甚至会起反效果。对于一个项目而言需要的往往不是更多的成员,而是适量的合适成员。
每一个人因为不同的教育背景,从业背景,项目经历(技术选型,学习经历,项目管理)对程序开发都会有不同的理解和思维模式。反应在业务上就是各种各样的代码风格。举例来说:有些人恨不得把所有单一功能都一一独立出来封装成类,而有些人却喜欢一个大类洋洋洒洒写上上千行。大部分情况下我都是倾向于前者,但是就像我时常吐槽的那样:It depends。不仅仅是软件开发,几乎所有的事到最终都会归结到一个统一的问题上:怎样才是一个度?
一群理念相去甚远的人在一起工作是件异常痛苦的事:相当一 部分的时间会浪费在解释,争论和排遣由此带来的沮丧和愤怒上。古人语:道不同,不相为谋。但到了真正的工作中却不能如此随性,缺乏足够动力的老人,能力出 众的技术骨干,干劲十足却缺乏经验的新人都需要互相体谅,学习和磨合。所以大部分的创业团队的技术团队因为理念相近,往往效率会足够高,而大公司内的开发 小组却永远无法达到那样的效率,更需要相应的规范和程序框架。
得 出上面这个结论的另一个理由是我对人的可塑造性是持悲观态度的:多数人并没有跳出自己思维局限性的意愿,动力和能力。少数人在没有任何外界压力的情况下仍 会不断总结学习进步(主动学习型),而其余的人要么没有任何意愿,关心的只是完成任务和拿到工资而已,要么想要进步而不得法。而你的团队不可能全由主动学 习型的成员组成,这时候规范和程序框架的引入才能够让各种类型的人更好的合作。
合适的规范
大 家都理解软件开发需要合适的规范:代码规范,程序规范,流程规范等等,以此来减少意外的出现:最少惊讶原则。但在实际执行中却会碰到各种情况,其中最大的 问题是:怎么鉴别哪些规范是需要强制执行,那些规范是推荐执行。规范的强制执行带来的是代码的可读性提升和二义性减少,而坏处也是显而易见的:对于大部分 有想法的程序员而言这种规定太死板,容易引起抵触心理,产生不安定因素。这种情况常见于各种标准的外包公司。
而 如果大部分的规范设定为推荐执行,在没有良好的引导下,规范容易被忽视。 网上有很多关于ObjC的代码规范,比如苹果自家的规范和《Google Objective-C Style Guide》等。这些规范一般只有两种分级:推荐和不推荐。而我更推荐把代码规范分成五个等级:强制要求,强烈推荐(但不强制),良好,可接受和不可接 受。以下仅举部分例子加以说明。
合适的框架
一个合适的框架不是银弹,在我看来框架要解决的问题从来不是:有了框架之后,工程就能无比正确地进行下去。好的框架能够做到的事仅仅只是:降低通用问题的复杂度和减少发生错误的可能性。个人认为一个良好iOS App框架应该是有如下特点:
各 层根据业务逻辑的复杂性内部又会使用单层或者多层结构。以数据访问层为例,一般又可以细分为网络层,持久化层。而一般而言,展现层(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江湖)