LuckyHu Blog

首页 产品 工作室

论多团队协作开发的app架构设计

31 Jan 2016

真的好久好久没有写博客了,年终总结都拖了3年了…有些事情我真的还没想清楚,等我想清楚了写个5年总结吧

先说问题

言归正传说说技术架构的事情,目前随着移动开发越来越成熟,大型APP也越来越多了,动则30万行以上代码量的工程也越来越多了,随着代码量上涨,工程越来越庞大,一般情况下公司为了方便管理和一些实际的产品发展的需要,会把客户端团队分拆成多个小团队各自独立开发需求,现在按发布APP算整Team的话,客户端工程师很容易就超过20个人了,我个人经验超过10个人的团队,如果分工和架构设计不合理,很容易就会出现扯皮的事情,这个情况我自己经历和听说都很多了。

如果没有专门针对这种大规模的客户端团队去设计合适的架构,常见的问题一般都是下面几种,首先假设整个客户端团队又分为a,b,c,d四个小团队:

这里我列举的三种情况只是我经常遇到或者听说过的case,实际上可能还有很多其他蛋疼事情没有涵盖进去,但大家可以看到,这里有些问题是通过一些简单粗暴的手段是可以解决的,我的前提条件设置比较简陋,就是这个团队的架构师完全没有任何这方面的概念,或者压根就没有人去用心思考过架构的问题。

实际需求

客户端的架构设计应该是个什么样的,应该以需求出发,这里我总结了一下我自己遇到的大部分情况的实际架构诉求,也就是一个客户端工程通常包含哪些部分:

不管哪个客户端总会需要处理很多和具体业务无关的纯技术需求,比如语音播放,视频播放,网络,长连接,推送等等,这部分通常大家都会有专门的一层和专门的人来维护

这一部分在大部分复杂的app中都是存在的,但在实际的架构设计中,又有不同的处理方式

这个部分的复杂度和粒度是和实际产品以及团队的划分相关的,可大可小

这里我用了‘发布出口’这个词,其实是我自己意淫的,我只是想更严谨地表达发布的这个概念,因为它不一定就是一个工程一个项目,很可能就是一个脚本,具体看怎么做了

这个样子

根据实际需求来说,最终整个客户端的架构设计应该是这个样子的:

架构图

好吧,看了这个架构图,很多人会觉得我说了一大堆废话,因为大部分的客户端架构都大约长这个样子,但实际上我看过的很多项目都只是概念上是这个样子的,随着产品需求不断改动,实际上的模块基本上最终都成了一坨,除非特殊需要的时候,是不会有人去把这个架构坚持维护下去的。所以为了让它可以持续地保持可供大型客户端团队进行迭代开发而不变形,我们应该有些原则性的东西在里面。

我认为每一个方块代表的部分都应该遵循一下几个原则:

如果加上了这几条原则,那么我们的最终架构图的层级没有改变,但会成为一个包含很多映射关系的拓扑结构,抱歉xmind用得太烂,画不好,懂我的意思就行了:

架构图2

简单来说,其实就是把团队内部的开发方式搞成了类似接入外部sdk的开发式,但是我们模块间调用上隐含了更多的产品逻辑上的依赖,包含了更多整个产品层面上定制化的东西,所以又不能完全采用外部sdk的方式进行开发。

复盘问题

针对之前提到的几个问题,这样的设计是不是真的解决问题了可以一个一个看:

原则一和三由于物理隔离和单独编译运行,让各个产品线之间的开发调试各自独立进行互不影响,小团队内部的错误不会向大团队扩散。

原则二的版本管理,让各个模块都可以灵活地进行升级和回滚并且对其他模块产生最小的影响

关于损耗

上面讲了解决的几个问题,但任何架构设计解决了一些问题必然会引入另外一些问题:

关于粒度控制

如果不单独写一套粒度控制模块,各个平台理论上最差都可以做到页面级别的粒度(客户端开发很多东西都和ui关系比较紧密),比如Android上的Activity和Fragment以及ios上的UIViewController,但如果希望进行更精细的粒度控制,那就必须做一些代码设计了,这个做法千差万别,我觉得找到最适合自己团队的方式就好了。

Different Platform

其实以上的这些东西是不分平台的,不管是ios还是android理论上都可以这么设计,不同点在于工程构建工具的选择上面,只要能包含版本管理,工程依赖,资源管理的工具我觉得就可以满足需求了,ios开发推荐cocoapods,应该没有其他更合适的了,android平台maven和gradle听说都很厉害,实在找不到合适的,自己针对性地开发一套,成本也不会非常高,只是要趟很多蛋疼的坑罢了,其实用工具也会趟很多坑..

好吧,我的逼装完了,感觉用架构这个词会被很多人喷得体无完肤,毕竟很多工程师都不喜欢被别人架构,但这里又找不到合适的词表达这个意思,如果觉得这个东西说得太简单没什么收获,绕道就好了,求不喷