手机天猫解耦之路.docxVIP

手机天猫解耦之路 作为技术团队，我们升级技术架构有各种缘由，而什么什么因素是最关键的，什么可以成为进化理由？ 业务升级 最重要的因素肯定是业务升级。一个不能产生业务价值的技术是不值得关注的，更不值得去实施。 好技术永久要比业务先走一步，在前边不远的地方等着业务追上来——技术驱动业务。所以业务不断升级，就要求我们的技术架构要跑的更快。 团队规模 合作模式 另一个推动架构进化的重要因素就是团队规模。技术架构最重要的作用之一是保障生产效率和生产质量。那么人的因素就格外关键。人多了，合作简单了，技术架构就必需升级，去保障这么多人在一起工作的时候，效率高，不出问题。 代码规模 工程规模 代码和工程的规模是一个自然进展的结果，业务简单了，团队大了，人多了，代码规模和工程规模必定上升。一个数十万DAU的App和一个千万DAU的App，规模上的差距虽不是必定，却也是极或许率了。 一个人，几十个文件，完成一个简约功能的产品，和十几个人，数千个文件，功能简单的产品，进一步到十几个团队，数百个模块，一个平台及产品的技术架构必定千差万别。 新技术 新技术，就是工程师本人的事了。业界总会有新的技术出来，这个技术可能是别人家工程师，为了顺应他们的业务进展和架构演化而研发出来的。但是技术没有边界，新技术好，能给我们带来价值，提升我们的效率，那我们就拿来用。 举个例子：Facebook的RN出来，我们都觉得不错，应当也有很多公司的确大规模的使用了。大规模的使用RN做开发，也就会对你本来的架构提出升级的要求。 当然更重要的是如何去平衡快速升级技术架构的古怪???心和恰好满足业务与团队要求这两件事。过度追求技术架构革新，过度追求新技术，不但不能给业务和团队带来推动作用，反而会形成灾难。所以，作为一个优秀的技术团队永久要权衡做或不做，多做或少做。 架构怎样进化 架构进化体现在哪些方面，作为一个技术团队我们要如何把架构进化落地？这个问题因项目而异，因团队而异，因方向而异。本文只引见手机天猫在进展过程中，与解耦相关的进化历程。 升级开发模式 开发模式的概念有点大，本文就只争辩和解耦这件事相关的：团队合作方式和工程组织方式。下文单独一节聊这个事，此处不赘述。 各维度解耦 工程大了以后，要分拆，不管是组件化还是插件化，还是什么，解耦是第一步，而且是各个维度的解耦。 完善工具集 模式演进的过程中，解耦的过程中，就会衍生出很多的工具。在进化过程里我们也会去思考，哪些工作是需要工具化的，自动去开发工具。一个完善的工具集，会极大提升团队的生产力，可以说是最有价值的部分。 开发模式升级 手机天猫团队从一个三端不到十个人的小团队，成长到现在一个接近两百人的大团队，后文具体描述开发模式经受了怎样样的变更？ 一个工程 三年前，手机天猫团队刚刚组建，十个左右工程师，开发第一版只具备基础功能的天猫App。整个团队就这么几号人，包括iOS，Android和Server三端，一个平台上也就三四个人；App的功能也格外简约，能完成基本的导购和买卖流程。 天猫App就使用了最简约的架构，独立工程，MVC架构。而且我们推断在这种情况下这样的架构是完全够用的，现实如此。 模块化 随着无线业务的进展，手机天猫的团队开头爆炸式的扩张。很快一个团队变两个，两个变四个。随着团队添加，消灭团队分工，工程也越来越大，我们开头发觉原始的架构已经开头不够用，拆分模块势在必行。 在这个阶段，手机天猫的模块拆分也做得格外简陋。先按功能把工程做横向分层，在业务层再做纵向梳理。把不同的模块代码简约的放在一个文件夹里，而工程的组织方式并没有发生变化。 如此拆分，我们做到代码独立，跨团队基本不会在同一个模块代码上产生冲突。 插件化 进一步进展，业务越来越简单，团队工作愈加细分，人也越来越多，代码量越来越大。简约的使用文件夹来组织模块的方式显得力不从心。多业务跨团队，不同的开发节拍，简单的依靠关系，导致我们会花掉大量的时间处理编译不过的问题。等待其他模块集成这件事竟然成了我们开发效率最大的瓶颈。 如何处理这个问题，我们的方案是插件化。那么插件和模块有什么区分？我认为二者最大的区分在于独立性。插件是可以独立开发，独立发布，独立运转的，而模块则必需依靠主工程的环境。具备独立性的插件可以很好的隔离跨团队之间的依靠，彼此独立开发，依据各自的节拍发布版本。 基于这样的思考，我们引入依靠管理设备（iOS引入了Cocoa Pods，Android使用Maven）；把此前的模块进一步剥离成独立工程，单独做版本管理；每个独立的插件对发布的版本号担任，不论是其他插件还是主工程都依靠插件发布的稳定版本。 然而，但是，But，插件化这件事并没有我们想象的那么奇特。代码出来了，但是不能独立编译，依靠管理设备有了，但是管不好。由于我们此前从未梳理过依靠关系