企业微信本地部署版(下文简称为本地版)是从2017年起,脱胎于企业微信的一款产品。本地版的后台服务能独立部署在政府或者大型企业的本地服务器上。在一个已经迭代了7年的大型Android系统中,企业微信本地版不可避免地会暴露出一些遗留系统的特点。本文将探讨我们在实践中采用的一些行之有效的重构案例,以及如何让一个大型软件系统持续保持活力。
Martin Fowler 曾经说过这样一句话:
Let’s face it, all we are doing is writing tomorrow’s legacy software today.
你现在所写的每一行代码,都是未来的遗留系统。
很多人以为存在时间很长的就是遗留系统,但这其实是个误区。时间长短并不能作为衡量遗留系统的标准。判断遗留系统的几个维度是:代码、架构、测试、DevOps以及技术和工具。代码质量差、架构混乱、没有测试、纯手工的 DevOps(或运维)、老旧的技术和工具,才是遗留系统的真正特点。
看看下面这 6 个问题是否在你的项目中也曾经遇到过。
如果你的产品也有类似的一些问题,符合的“症状”越多,你的产品就越趋近于一个遗留系统。当遗留系统这个泥球越滚越大时,我们对它投入的改造成本就会越来越高。遗留系统就像一辆老破旧的小汽车,不知道啥时候会出问题,维修成本也越来越高,想快也快不起来。
重构(名词):对软件内部结构的一种调整,目的是在不改变软件可观察行为的前提下,提高其可理解性,降低其修改成本。
小型重构是指对单个类内部的重构优化。通常包括对方法名称、方法参数数量、方法大小等内容的修改。中型重构是对多个类间的重构优化,通常的一些修改包括提取接口、超类、委托等调整。大型重构是对整个系统的架构进行重构优化,比如组件化、应用中台架构升级等,通常在做大型重构时也会伴随中小型的代码重构。以组件化为例,通过提取公用的基础组件和业务组件,来提高代码的可复用性,同时让业务能独立演进,就是一种大型重构。重构的目的是在不改变软件可观察行为的前提下,重点提高其可理解性,降低其修改成本。因此计算重构收益的方式很简单,从商业的角度来看,收益 = 软件价值 - (研发 + 维护成本)。
如果我们只注重业务上的价值而忽略了软件的研发维护成本,那么长此以往就会来到拐点 1。当研发维护成本超出业务价值,收益就开始负增长了。很多企业往往也是到这个拐点才意识到重构的重要性。
通常来说,重构需要一段时间的投入,来慢慢降低研发维护成本,有的需要几个月,有的甚至超过一年。但如果能坚持下来,就会来到拐点 3,此时收益开始正向增长。
这个模式是指我们在替换一个软件系统时,在旧系统旁边搭建一个新系统,让它缓慢增长,与旧系统同时存在,逐步地“绞杀”旧系统。这个“逐步”的意思,其实就是增量演进。“同时存在”指的是并行运行。
它有三个优势:第一,不会遗漏原有需求;第二,可以稳定地提供价值,频繁地交付版本,更好地监控其改造进展。第三,避免“闭门造车”。
劣势主要来自迭代的风险和成本,绞杀的时间跨度会很大,存在一定风险,而且还会产生一定的迭代成本。
最开始时,我们的启动任务逻辑全部都写在 Application
的 onCreate
中。随着启动逻辑越来越复杂,这部分代码越来越难以维护,而且很难监控每个版本中由于启动任务逻辑的变化,而带来的启动速度变化。
下图所示是一部分重构前的启动任务逻辑,各种业务的启动任务都写在 initMainProcess()
中。
重构后我们引入了启动任务管理框架,不同业务的启动任务划分到不同的Task中,按照顺序装载到对应的进程。
每个Task实现一个相对比较内聚的功能:
但是由于启动任务逻辑的复杂性,我们没有一次性把所有启动逻辑都重构成Task的形式,而是新逻辑使用Task的形式,旧逻辑逐步迁移。这种新旧写法共存的情况维持了相当长的一段时间,直到所有启动逻辑都最终迁移到了新的启动框架中,后续
Application
的 onCreate
中也不允许再增加新的启动逻辑。
重构后,启动Task的功能职责单一化,达到了高内聚、低耦合的目标。而且对于新增的启动任务,以及每个任务的速度劣化,都更方便监控了。
绞杀植物模式适合用于新的系统和服务,替换旧的系统或旧系统中的一个模块。在旧系统内部,也可以使用类似的思想来替换一个模块,只不过这个模块仍然位于旧系统中,而不是外部。我们把这种方式叫做修缮者模式。
修缮者模式是对于现有系统新增一层进行封装,然后在保证新层对外提供功能不变的情况下,对系统内部进行改造。
本地版客户端除了能连接到本地版的服务器,还能连接到Saas的云端服务器,实现这部分能力的模块称为云服务模块。
为了在同一个UI页面,同时支持使用本地版服务和云服务,我们基于这两个底层服务构建了一个中间分发层。中间分发层能够根据不同的情况,适当地将请求分发给本地版服务或者云服务。
Android开发中使用maven依赖其他模块时,有implementation和api两种方式,它们的区别是:
但是由于分发层的隔离不够严格,使用了api依赖云服务模块,导致业务层也可以绕过分发层,直接调用本地版服务或者云服务。业务层开发需要根据具体情况,考虑应该在什么情况调用哪个服务,增加了维护成本和出错的概率。
我们针对分层不够清晰的问题,重构了一套严格编译隔离的云服务底层:业务层调用者必须通过中间分发层调用本地版服务或者云服务,无法绕过中间层。
具体的做法是改成使用maven的implementation依赖方式,使得云服务底层的maven依赖不会传递给业务模块,保证只有中间层能够调用云服务底层,而业务层只能依赖中间层。
重构的过程是可以小步进行的:先把一个业务模块对云服务底层的依赖改成只依赖中间层,然后编译,接着逐个处理编译错误。处理完一个业务模块就可以提测这个模块。
在保证新的中间层对外提供功能不变的情况下,我们渐进式地对中间层进行了重构,逐个模块地把非预期中的跨层依赖都剥离掉。
整个过程修改的Java文件数量超过800+,从此业务层只能通过中间层调用本地版通用底层或者Saas通用底层,跨层调用都会直接报编译错误。
基于原有的业务,新写一套系统,然后一次性将旧系统的数据和功能,迁移到新系统上。
我们本地版原来已经有一套页面生命周期的监控模块,后来又引入了一套Saas的页面生命周期监控模块。两个模块的功能大部分重复又不完全相同,维护的成本很大,比如开发做一个功能可能得同时修改两个模块的代码,而且两个模块的修改都是类似的。
虽然这个模块的改动影响很大,但是为了彻底解决遗留代码带来的问题,我们在一次迭代中合并了两个模块的代码,一次性切到新的唯一一个生命周期监控模块中。
在本节中,我会介绍两个架构重构的案例:组件化和云服务ProtoBuf定义统一。一般来说,挑战可以归纳成两大类。首先是普遍性挑战,比如组件化重构,我将会展示我们是如何深入理解业务需求,找到量身定制的组件化重构方案。其次,是特有的业务挑战。以本地版为例,我们面临的是历史遗留问题,比如本地版和Saas两种冲突的PB定义共存的情况。这种独特的挑战要求我们不仅要有技术上的广度,还需要深度和创造性地思考。接下来,我将分享我们如何安全小步地实施架构重构,同时保持系统持续迭代。
单体架构是常见的架构模式之一。通常所有开发人员基于单个模块进行开发,所有业务功能都集成在一起打包发布。单体架构非常适合团队规模小、业务复杂度低的产品,在项目起始阶段能快速迭代进行验证。
随着业务的持续演进,代码不断地膨胀和腐坏,所以代码内部的耦合度很高。在这样的基础上修改代码,非常容易牵一发而动全身:修改一个 Bug,又引起另外一个 Bug;开发一个功能,又引起另外一个功能的异常。
这里先简单讲述一下企业微信组件化的技术方案,但是不会涉及太多细节。
组件间的通信方案使用接口,即每个模块各自提供一批对外的api接口,其它模块只能访问到这些api,如图:
工程结构上使用Module这种官方的形式进行工程结构拆分,各组件之间能只能访问到对方的api,通过只依赖api而不依赖本体的形式来实现的代码隔离。
组件化方案确定后,解耦遗留代码的过程是漫长而琐碎的。这里我更想着重叙述下本地版是如何推进组件化项目的进度,以及提高组件化实施的效率的。
一个完整的组件化重构步骤如下图所示:
划分出不同功能模块的分界线后,我们把不同模块的解耦任务分给对应负责的开发。然后我们做了一个网站自动监控每个模块的解耦进度:
统计每日的解耦类和api数量:
我们通过这种方式持续推进这个维持了一年多的组件化大型重构项目,让每个模块的解耦进度和组件化程度都可以一目了然。
组件化的过程中,最常见的操作就是把更为内聚的一些类移动到同一个组件内,以及为隔离的组件提供对外的API接口。为了提高组件化的效率,我们开发了许多解耦代码的脚本,用于抽取组件API、移动类、移动资源,大大提高了全组开发实施组件化的效率。
自动化重构脚本分析和移动基础库ui_foundation的执行示例:
2. 抽取业务模块30+,抽取接口数2200+
由于本地版的历史需求和Saas既有相同也有不同的地方,所以造成了两者的ProtoBuf有大量相同重合的地方,但是少量字段又并不是完全一样的。而且在开始没有开发规范的情况下,产生了冲突的数据字段,也就是在同一个Message结构体的相同位置的字段,在本地版和Saas中的类型或者含义是不一样的。
虽然后面我们已经意识到这个问题,对本地版需求新增加的ProtoBuf字段索引都增加了1000,以此避免冲突,但是历史已经放出去的版本也无法再修改。如果没有一个兼容旧版本的方案,那冲突的字段只能一直保留着。
在本地版的业务层中,本地版的ProtoBuf和Saas的ProtoBuf一起编译,由于不能存在包名和类名都一样的类,所以本地版的ProtoBuf包名都从wework修改成了weworklocal。因此业务开发需要关注当前使用的是哪套ProtoBuf,而选择引入不同的包名,大大增加了代码的理解成本和开发成本。
为了实现两套通用底层的PB统一,最大的问题是如何兼容两份PB的冲突字段。本地版PB和SaasPB的字段冲突类型,主要有4种:
为了解决PB字段冲突的问题,我们增加了一个冲突转换层:
针对重复性工作,我们使用脚本对比Proto,找出冲突字段并进行自动化处理,提高效率,流程如下:
自动化重构脚本方案收益如下:
将大型的单体遗留系统重构为组件化架构后,我们有了更加低耦合、高内聚的组件。但是回到组件内部,代码质量对开发也非常重要。我相信你在过去的代码里一定会遇到一种典型的代码坏味道,那就是“过大类”。在产品迭代的过程中,由于缺少规范和守护,单个类很容易急剧膨胀,有的甚至达到几万行的规模。过大的类会导致发散式的修改问题,只要需求有变化,这个类就得做相应修改。
随着业务需求和代码规模的不断膨胀,我们针对过大类的重构策略就是分而治之。通过分层将不同维度的变化控制在独立的边界中,使之能够独立的演化,从而减少修改代码时彼此之间产生的影响。
对于遗留系统来说,比较常见的问题就是需求的上下文中容易存在断层,所以第一步就是尽可能地了解、分析原有的业务需求。只有更清楚地挖掘原有的需求设计,才不会因为理解上的差异出现错误的代码调整。接下来我们以会话列表页面为例,讲述我们重构过大类的过程。下图是我们对会话列表涉及的业务功能进行的梳理:
下图是会话列表页面的示意图:
分析完之后,接下来就是进行架构设计了。这一步让我们在开始动手重构前,想清楚重构后的代码将会是什么样子,以终为始才能让我们的目标更加清晰,让过程更加可度量。
现在主流APP框架都是用一套MVP或者MVVM框架来解耦。企微还是传统的MVC方案,由于历史原因修改成MVP或者MVVM都会有非常大的成本。
于是我们创建了一个新的MVCs的框架。MVCs的主要理念是将View和Model的交互,变成一个可插拔的抽象的逻辑。所以一个Controller描述的是一组View与一组Model的关系,从理念上,它应与业务无关。MVCs架构在面对企微这种复杂度的场景下,已经可以较好得支撑实际面临的业务需求。
建立一个IController,抽象出和 Activity/Fragment相同的生命周期,然后在Activity/Fragment相同的生命周期执行。同时一个IController可以包含多个IController,先执行本身的逻辑,然后再执行子IController逻辑,同时提供懒加载方案LazyController ,当达到一定条件的时候才会加载,保证性能和效率。
基于MVCs,我们将页面重构成了各个不同的Controller,把旧页面超大类中的一个个业务逐步拆分到独立的Controller中:
每个controller对应一个具体的业务场景,例如:
在采用MVCs框架进行重构后,平均每个Controller的代码行数降低到了约365行。这意味着我们成功地实现了Controller功能职责的单一化,达到了高内聚、低耦合的目标。
通过这些改进,我们的代码变得更加清晰、易读,降低了维护成本。同时,由于各个功能模块之间的耦合度降低,我们可以更加灵活地对现有功能进行修改和扩展,以满足不断变化的业务需求。这些成果充分证明了MVCS框架在实际项目中的有效性和可行性,为后续重构其他大型页面提供了有益的借鉴。
企业微信本地版有大量的网络通讯、数据库存储等底层通用能力是使用C++实现的,之前是以典型的Android.mk作为构建工具来构建动态库。Bazel则是更为现代化的构建工具:Bazel能够缓存所有以前完成的工作,并跟踪对文件内容和构建命令的更改,因此Bazel在构建时只对需要重建的部分进行构建;同时,Bazel支持项目以高度并行和增量的方式构建,能够进一步加快构建速度。
目前,本地版Android端的底层动态库已经全量换成使用Bazel构建,下面是其中一个构建脚本的例子:
因为本地版需要面向很多大型政企用户,不同的政企可能会有不同的包名、不同的发布分支、不同的发布计划,而且这些发布计划还会并行发布。为了让各个角色的成员都能清晰了解和管理当前正在发布的分支和迭代,我们开发了专门的分支管理页面,自动化拉取、合并不同的迭代分支,以及管理迭代的生命周期。
本地版客户端的模块众多,不同的模块可能是由不同的团队负责开发的。下面是我们依赖的一些跨仓库组件的示意图:
不同的组件由不同团队维护的流水线构建,最后以maven的形式集成到本地版企业微信APP中。当分支管理工具拉出一条新分支时,就会自动实例化各个业务组件的子流水线。这样我们可以做到即使在多团队、多仓库、多分支开发的情况下,组件编译和集成编译都可以全自动进行。
冰冻三尺非一日之寒 ,遗留系统不是一天就产生,也不单纯因为一次提交就演化而来,而是随着不断的版本更迭、人员变换、代码不断累积腐化而导致的。
遗留系统的技术债务就像一座冰山,虽然表面平平无奇,但是底下却是纵横交错。可怕的是很多时候我们却只看到了表面,而却无法真正发现阻碍产品快速演进的元凶。
主动、持续地改进甚至重构系统,才能适应变化。遗留系统重构的最终目标是构建一个具有可扩展性、高性能、高可用性的系统架构,提高系统的开发效率和产品的迭代速度。
本文由哈喽比特于7月以前收录,如有侵权请联系我们。
文章来源:https://mp.weixin.qq.com/s/QwKBNaTbaXUGJVEYsHdiNQ
京东创始人刘强东和其妻子章泽天最近成为了互联网舆论关注的焦点。有关他们“移民美国”和在美国购买豪宅的传言在互联网上广泛传播。然而,京东官方通过微博发言人发布的消息澄清了这些传言,称这些言论纯属虚假信息和蓄意捏造。
日前,据博主“@超能数码君老周”爆料,国内三大运营商中国移动、中国电信和中国联通预计将集体采购百万台规模的华为Mate60系列手机。
据报道,荷兰半导体设备公司ASML正看到美国对华遏制政策的负面影响。阿斯麦(ASML)CEO彼得·温宁克在一档电视节目中分享了他对中国大陆问题以及该公司面临的出口管制和保护主义的看法。彼得曾在多个场合表达了他对出口管制以及中荷经济关系的担忧。
今年早些时候,抖音悄然上线了一款名为“青桃”的 App,Slogan 为“看见你的热爱”,根据应用介绍可知,“青桃”是一个属于年轻人的兴趣知识视频平台,由抖音官方出品的中长视频关联版本,整体风格有些类似B站。
日前,威马汽车首席数据官梅松林转发了一份“世界各国地区拥车率排行榜”,同时,他发文表示:中国汽车普及率低于非洲国家尼日利亚,每百户家庭仅17户有车。意大利世界排名第一,每十户中九户有车。
近日,一项新的研究发现,维生素 C 和 E 等抗氧化剂会激活一种机制,刺激癌症肿瘤中新血管的生长,帮助它们生长和扩散。
据媒体援引消息人士报道,苹果公司正在测试使用3D打印技术来生产其智能手表的钢质底盘。消息传出后,3D系统一度大涨超10%,不过截至周三收盘,该股涨幅回落至2%以内。
9月2日,坐拥千万粉丝的网红主播“秀才”账号被封禁,在社交媒体平台上引发热议。平台相关负责人表示,“秀才”账号违反平台相关规定,已封禁。据知情人士透露,秀才近期被举报存在违法行为,这可能是他被封禁的部分原因。据悉,“秀才”年龄39岁,是安徽省亳州市蒙城县人,抖音网红,粉丝数量超1200万。他曾被称为“中老年...
9月3日消息,亚马逊的一些股东,包括持有该公司股票的一家养老基金,日前对亚马逊、其创始人贝索斯和其董事会提起诉讼,指控他们在为 Project Kuiper 卫星星座项目购买发射服务时“违反了信义义务”。
据消息,为推广自家应用,苹果现推出了一个名为“Apps by Apple”的网站,展示了苹果为旗下产品(如 iPhone、iPad、Apple Watch、Mac 和 Apple TV)开发的各种应用程序。
特斯拉本周在美国大幅下调Model S和X售价,引发了该公司一些最坚定支持者的不满。知名特斯拉多头、未来基金(Future Fund)管理合伙人加里·布莱克发帖称,降价是一种“短期麻醉剂”,会让潜在客户等待进一步降价。
据外媒9月2日报道,荷兰半导体设备制造商阿斯麦称,尽管荷兰政府颁布的半导体设备出口管制新规9月正式生效,但该公司已获得在2023年底以前向中国运送受限制芯片制造机器的许可。
近日,根据美国证券交易委员会的文件显示,苹果卫星服务提供商 Globalstar 近期向马斯克旗下的 SpaceX 支付 6400 万美元(约 4.65 亿元人民币)。用于在 2023-2025 年期间,发射卫星,进一步扩展苹果 iPhone 系列的 SOS 卫星服务。
据报道,马斯克旗下社交平台𝕏(推特)日前调整了隐私政策,允许 𝕏 使用用户发布的信息来训练其人工智能(AI)模型。新的隐私政策将于 9 月 29 日生效。新政策规定,𝕏可能会使用所收集到的平台信息和公开可用的信息,来帮助训练 𝕏 的机器学习或人工智能模型。
9月2日,荣耀CEO赵明在采访中谈及华为手机回归时表示,替老同事们高兴,觉得手机行业,由于华为的回归,让竞争充满了更多的可能性和更多的魅力,对行业来说也是件好事。
《自然》30日发表的一篇论文报道了一个名为Swift的人工智能(AI)系统,该系统驾驶无人机的能力可在真实世界中一对一冠军赛里战胜人类对手。
近日,非营利组织纽约真菌学会(NYMS)发出警告,表示亚马逊为代表的电商平台上,充斥着各种AI生成的蘑菇觅食科普书籍,其中存在诸多错误。
社交媒体平台𝕏(原推特)新隐私政策提到:“在您同意的情况下,我们可能出于安全、安保和身份识别目的收集和使用您的生物识别信息。”
2023年德国柏林消费电子展上,各大企业都带来了最新的理念和产品,而高端化、本土化的中国产品正在不断吸引欧洲等国际市场的目光。
罗永浩日前在直播中吐槽苹果即将推出的 iPhone 新品,具体内容为:“以我对我‘子公司’的了解,我认为 iPhone 15 跟 iPhone 14 不会有什么区别的,除了序(列)号变了,这个‘不要脸’的东西,这个‘臭厨子’。