最新公告
  • 欢迎您光临欧资源网,本站秉承服务宗旨 履行“站长”责任,销售只是起点 服务永无止境!立即加入我们
  • 字节跳动抖音研发工具链面临的挑战与问题(组图)

    MBox是字节跳动抖音基础技术团队和Client Infrastructure团队针对移动端研发的现状和问题,结合移动端研发工具的实践经验,开发的一款面向移动开发者的研发工具链产品. 目前MBox CLI(命令行工具)已经开源,未来会增加更多平台支持。欢迎试用。

    现状和问题

    随着公司的快速发展,移动端研发呈现以下现状和趋势:研发团队规模参差不齐,工程化和组件化解决方案不尽相同,跨端研发成为常态,中台业务不断扩大。现状使得移动终端开发不得不面临以下问题:日益复杂的研发环境和工程结构。

    在大前端的背景下,移动研发环境呈现出丰富的技术栈背景,这也导致了研发环境的复杂性增加。研发环境的部署是预编码工作。这也是新人对团队研发经历的第一印象。所以研发环境的问题会给团队带来很多麻烦。事实上,在研发环境中遇到问题的不仅仅是新人才。随着工程的进步,环境问题将继续困扰着所有团队成员。环境版本不一致、工程环境冲突、文档更新频繁会导致研发人员将大量精力浪费在环境上,而不是核心编码和测试阶段。

    很多移动开发者经常面临超大型项目或多个项目并行开发的场景。项目的工程结构往往非常复杂,通常体现在多仓库依赖管理困难、发布过程繁琐、多人协作困难等方面。大,极大地影响了研发效率。这是另一个想法。上述一些问题,其实是在工程改造过程中引入的。这是否与工程提高效率和确保质量的目的相矛盾?

    渐渐地,研发过程越来越繁琐,研发效率难免受到影响。可能是研发人员一开始会抱怨,但久而久之就会变得正常。

    工具链挑战半自动化流程

    在移动端开发的场景下,虽然研发人员看似丰富的研发工具可以解决上述环境和工程问题,但开发者往往会觉得工具找不到、工具用不上、工具不好用。. 理想情况下,工具链中每个工具的输出或结果环境都会成为下一个工具的输入或启动环境,但在移动开发的实践中,工具链之间的输出和输入转换往往需要开发者手动完成,这大量重复操作也成为研发人员抱怨的焦点。

    维基百科:工具链是一组编程工具,通常是另一个计算机程序或一组相关程序。

    拆分管道

    每个研发团队都有自己的研发管道(审查、开发、构建、测试、修复和发布)。在提高研发效率的实践中,我们往往会提供丰富的研发工具供研发人员在这些流程节点使用,但这些工具真的融入我们的研发流程,形成完整的工具链了吗?

    现实情况是,我们在实践中往往过于关注单一指标。比如通过工具链的改造提高项目的工程化程度,工程化确实可以提高可维护性、工程质量等指标,但是在其他环节,比如新人入手成本的增加、依赖管理的难度、代码集成时间的延长、bug再现的难度等也带来了负面影响。

    计划

    我们分析了上述现状和问题,并结合移动端研发工具的实践经验,最终决定为移动端开发者开发一款研发工具链产品MBox。

    如上图所示,MBox的最终产品形态是一个Navtive App,包含GUI(Graphical User Interface)和CLI(Command-Line Interface)。

    主意

    全覆盖多合一

    我们期望开发出能够覆盖整个研发流程的工具链产品。用户可以在MBox中获取所有需要的研发信息,完成相应的研发工作,同时保证整个研发链的研发一致性。经验。

    可视化

    在CLI版本的初始迭代过程中,我们逐渐发现可视化交互方式可以解决一些CLI交互中难以解决的问题。尽管 GUI 在编程方面比 CLI 复杂得多,但我们坚信用户体验的重要性。因此,MBox 为用户提供了 GUI 和 CLI 两种可供选择的交互方式。

    非常简单

    这里的简单并不意味着简单,而是交互设计中的简单,本质上是可用性的体现。我们认为研发工具应该为用户解决问题,而不是制造困难。任何不相关或分散研发人员注意力的信息都是不必要的。简单易用是对研发工具最美好的赞美。

    可扩展可扩展

    一般来说,一体化工具链通常会导致可定制性差。MBox通过插件技术最大程度满足用户的横向和纵向扩展需求。

    建筑学

    如前所述,我们的研发流程通常是一个流水线模型,大部分研发工具都会从这个流水线中找到一个入口点来提供服务,协助用户完成某个节点的工作。在架构设计上,MBox更注重整个研发过程的效率,不仅体现在单个节点的效率上,还体现在不同节点之间的流动效率上。

    MBox的功能并不是按照研发流程来划分,而是整个研发环节贯穿所有功能设计,按照功能类型分为四大板块:Environment、Workspace、Workflow、Tool。

    核心功能环境

    环境是研发环境。直觉告诉我们,环境部署只是研发过程中比较前端的一个环节,但在实际开发实践中,Environment需要解决的不仅仅是部署问题,还需要解决环境统一(Consistency)、环境升级(Upgrade)和环境隔离(Isolation)这三个问题,而以上四个问题贯穿于整个研发过程。

    我们认为,在良好的研发体验中,研发人员不需要关注大部分与环境相关的问题,而应该更加专注于业务,产生更多的有效价值。MBox实现了全过程的自动化。可随时为研发人员提前完成与环境相关的部署、隔离和升级工作,无需感知。同时也解决了项目研发环境的一致性问题。

    上图为GUI下的环境功能模块。除了上面提到的全自动化能力,MBox 还支持用户手动控制。

    工作区

    工作区是我们存放代码仓库的空间,也被认为是研发人员工作的核心。我们可以先回顾一下,我们一般是如何管理代码的?在这个过程中我们遇到了哪些问题?

    下面将描述我们在实践中遇到的困难以及相应的解决方案。

    挑战 1:跨项目开发多个项目

    在一些研发团队中(常见于中台部门),经常需要在多个项目之间同时进行开发。每个项目的代码库和研发环境往往相差很大,在切换项目的过程中,研发往往会被耗尽。各种仓库和环境问题导致效率降低。MBox采用沙盒技术,将不同项目的代码仓库与环境隔离。我们将这样的沙盒称为MBox Workspace(以下简称Workspace)。在这种机制下,开发者只需要明确自己当前需要开发哪个项目,而无需关注这个项目背后的问题。

    挑战 2:回购太多

    随着团队的壮大,工程和组件化不断深化。理想情况下,每个业务团队只需要专注于自己开发的组件,代码在仓库级别进行隔离。这确实会带来很多缓存、二进制,并且在安全风险控制等方面都有优势,但这也可能会导致一个通病,那就是仓库数量多,难以维护。

    在 MBox 中,开发者可以方便地将远程或本地仓库添加到 Workspace 进行统一管理。同时,在同一个Workspace中,我们还使用缓存技术来加快添加仓库的进程,使仓库的增删更方便快捷。

    除了仓库的增删改查,Git仓库操作是研发人员最常用的。MBox参考行业成熟的解决方案,结合自身的实践经验,通过CLI和GUI两种方式为研发人员提供多仓库批量操作的支持。

    以上展示了GUI下的多仓库提交流程。在终端中,用户可以使用 mbox git xxx 命令完成多仓库批量操作。

    挑战 3:需求变化

    大多数研发人员经常面临需求变化的问题,例如同时开发多个需求或临时修复错误。在 GitFlow 模型下,研发人员需要根据当前的需求来回切换相应的分支,尤其是在多仓库开发中,频繁的需求变更会给开发者增加显着的成本。

    MBox 通过简化 GitFlow 模型,提出了 Feature Mode 的概念。每个需求(即仓库、分支、代码)的元数据都被抽象为一个 Feature。每个 Feature 相互独立,互不影响。在需求之间快速轮换。

    从上图可以看出,当前Workspace中有3个Feature,即feature1 feature2 bugfix,每个Feature都有自己对应的同名分支。此外,MBox 还具有 Free Mode 的状态。在这种状态下,开发者可以对仓库进行任意操作,作为切换到 Feature Mode 的前期准备。

    挑战四:对复杂依赖的依赖

    易用性测试 文档测试_hp1005打印机测试页能打word文档打印不了_画论丛刊明代画家唐志契用山性即我性

    在移动端本地开发中,我们经常需要用本地仓库中的源代码版本替换一个组件依赖,同时我们还需要仔细维护本地仓库的代码版本,保证与集成的一致版本。

    MBox拥有一套完整的依赖管理解决方案,结合不同包管理工具的特点,采用多种技术实现依赖包的本地重定向,开发者只需一行命令或点击几下按钮即可完成操作,越多越好。可以减少研发人员的重复性机械工作。

    同时,通过一套抽象的依赖管理解决方案,我们在一定程度上抚平了依赖管理工具之间的一些差异。即使在跨端开发中,研发人员仍然可以获得相对一致的研发体验。例如,在组件化的研发场景中,我们需要依赖组件A的本地源码版本。Flutter和iOS平台常用的包管理工具对应的CLI命令有:

    $ mbox add component_A
    $ mbox pub get
    

    $ mbox add component_A
    $ mbox pod install
    

    挑战五:协作难度协作

    随着团队的壮大,团队成员之间的协作变得更加紧密,但同时项目的复杂性也随着团队的壮大而增加。如何将自己的研发进度及时完整地同步给他人,成为提高团队协作效率必须解决的问题。

    Feature Mode的抽象过程上面已经讲过了。事实上,Feature 不仅可以让单个开发者快速切换工作上下文,还可以让不同的开发者共享当前状态下的所有代码仓库和研发环境。

    我们还可以发挥更多的想象力。如果将此功能扩展到云平台,比如异常监控平台,服务器会构造一个会导致崩溃案例的特征,研发人员会在本地导入,以快速将出现bug的场景复制到本地。

    工作空间的优势

    结合以上五个挑战,我们提出了相应的解决方案,即使用沙盒技术解决跨项目开发问题易用性测试 文档测试,使用多仓库管理技术解决仓库数量扩展问题,提出Feature的概念来解决多项目开发问题。要求并行。问题,利用依赖管理技术解决依赖控制效率低下的问题,最后提出同步特性解决多人协作困难的问题

    工作流程

    与研发过程相关的云服务

    在大型工程团队中,为了提高研发质量和效率,会推出很多与研发过程相关的云服务。这些服务一般通过前端页面或命令脚本对外提供。但是,很多云服务都面临着同样的问题,无法及时到达每一个研发人员,落地往往需要一定的时间,研发人员也需要付出一定的学习成本。我们一直在思考如何帮助那些优秀的云服务实现价值最大化?

    在实践中,我们发现云服务结合MBox的原生优势,不仅大大降低了用户的学习成本,还扩大了云服务的使用范围。

    上面提到的MBox与异常监控平台的联动是一个很好的应用场景。监控平台通过MBox直接为研发人员创建本地开发环境,将云服务的应用场景延伸至本地研发人员。云平台可以通过MBox实现与研发人员本地机器的联动,研发人员也可以通过MBox直接使用在线云服务。可以说,Native 解决了云服务工具“到达用户最后一公里”的问题。这些云服务带来了更大的想象空间。

    智能错误诊断

    在移动研发中,相当一部分工具链运行在开发者的本地机器上,这使得我们无法实时获取开发者本地的运行状态,也增加了排查的难度。此外,研发人员在研发过程中遇到错误或问题时,也缺乏自查的方法。在大多数情况下,他们只能向同事寻求帮助或发起 Oncall。

    MBox利用其作为一体化研发工具的优势,收集研发人员在各个流程中遇到的错误日志,进行分析和分类,第一时间为研发人员推送解决问题的方法。尽量减少工具问题对研发效率的影响。作为工具链开发者,可以通过不断添加解决方案来优化错误诊断流程,积累常见问题的知识库,提高人工 Oncall 的预拦截率。

    工具

    MBox不仅仅是一个研发工具,它更像是一个可以承载更多研发工具的平台。MBox 开放了所有核心能力,所有开发者都可以以插件的形式进行开发。工具与更多开发人员共享。

    为什么选择原生应用?

    核心功能介绍完了,最后我想说说为什么要做一个Native App。

    在大多数传统实践中,我们经常使用“工具+平台+文档”的紧密配合来保证整个研发过程的运行。然而,正是这种密切的关系,很容易导致三者相互影响,阻碍发展。按照这个思路,既然三者关系如此密切,那么有没有这样一种载体,将三者统一为一个整体,满足研发人员在研发过程中的所有需求,保证研发管线的效率?跑。

    既然是 Native 开发者,何不为自己开发一款好用的研发工具来提高工作效率呢?

    这个很酷的想法应运而生。就像把产品做成工具一样,核心是移动端本地研发。将产品思维应用到工具开发中,不断提高工具的可用性。我们坚信,只有具备高可用性的研发工具产品才能真正提升研发效率。同时,在产品思维的驱动下,我们也可以利用MBox建立性能衡量数据指标,发现研发过程中的关键问题,进行针对性的开发优化,形成使用产品->收集数据->的闭环改进产品。

    尼尔森对产品可用性的看法:易用性、交互效率、可记忆性、容错性、用户满意度

    开放性

    开放性赋予了工具链强大的生命力。

    打开能力

    MBox 在设计之初就使用了插件架构。完全遵循自下而上的插件化开发思路易用性测试 文档测试,尽可能的开放所有能力。用户可以通过MBox提供的开发者工具包开发自定义插件,实现自定义。能力。由于这种开放的定制能力,MBox 对研发过程的支持的广度和深度将不断发展。

    开放平台

    MBox 允许任何开发人员将自定义插件上传到插件市场。同时,团队的技术负责人可以结合团队选择所需的插件集。插件市场将负责同步团队中所有成员的插件及其对应版本。此外,所有用户还可以在插件市场的平台上浏览和安装任何对自己的研发效率有帮助的插件。通过这样一个开放的平台,来自多个不同研发团队的数十款插件已经发布到字节跳动内部的插件市场。功能覆盖研发的所有流程,开放的工具链生态系统已逐步建立。.

    如果说上述插件架构解决了“插件从哪里来”的问题,那么插件市场很好地解决了插件“去哪里”的问题。

    考虑完整的链接和可定制的

    在选择研发工具链时,通常有两种选择:

    一种是全链路工具,即一个完整的解决方案涵盖所有研发场景。在这种方案下,所有研发数据流动更顺畅,用户体验更好。

    另一种是定制化工具,即结合当前团队的研发流程、人员结构、技术特点,自由选择最适合的工具链组合,最大限度发挥各工具的优势。

    表面上看,MBox 似乎更像前者,即全链路工具,但本质上,MBox 所做的是整合后者的定制化工具集,解决各种工具之间的数据流转问题,以及提供一站式工具链服务,打造研发体系闭环。MBox 不是替换任何链接的工具,所以对于一般项目来说,MBox 的访问过程非常简单。我们的目的是连接工具和开发人员,以最大限度地提高研发效率和用户体验。

    重新讨论研发管道

    研发流水线的概念上面已经提到过。在传统的实践过程中,会围绕这条流水线诞生各种工具平台,协助研发人员完成这条流水线。但是,正如文章开头所提到的,大部分工具链在研发过程中都专注于某个节点,往往忽略了流水线节点的流畅性。

    为什么我们如此关心生产节点之间的流动顺畅度?

    在提高研发效率的实践中,提高生产节点流通效率与提高单个节点效率同等重要。生产节点的畅通其实体现在我们可以为用户提供一个高度灵活易用的生产工具,因为在实践中发现前端研发人员往往处于多变的境地变化的需求(同时开发多个需求或同时修复多个bug),变化的环境(开发环境经常需要升级或切换版本),变化的工具(技术进步带来的工具变化)。研发人员经常面对这些变化却难以应对,

    工具可以为研发人员提供足够的灵活性,这是保证生产节点流程效率的关键。MBox 有意识地为用户提供尽可能多的灵活性,支持从需求到编码、需求到需求、实施到准入、编码到编码、在线问题到本地检查等多个流程的灵活流动。

    结束语

    自智能终端设备诞生以来,移动终端研发蓬勃发展十余年。每个平台框架都开发了独特的工具链体系,每个大团队也建立了内部工具体系。,但正是这个独立成熟的工具系统,将成为束缚我们展示技术的牢笼。在大前端的背景下,技术栈的界限是模糊的。对于移动开发者来说,打破这些限制并将我们的经验和技术应用到更广阔的未来是令人兴奋的!最后,希望MBox在这方面的一些琐碎思考和工作,能够重新唤醒我们移动开发者改变世界的巨大愿望。

    还有一件事

    MBox CLI(命令行工具)已开源!现在支持 CocoaPods (iOS) 和 Bundler 项目,未来将添加更多平台支持。通过开源,我们希望更多的开发者能够加入到MBox的生态建设中来,为广大移动开发者带来一个优秀的研发工具。

    GitHub地址:

    参考链接加入我们

    我们是负责抖音客户端基础能力研发和新技术探索的团队。我们深耕工程/业务架构、研发工具、编译系统等,同时支持业务快速迭代,同时保证超大型团队的研发效率和工程质量。不断探索性能/稳定性等方面,力求为亿万用户提供最极致的基础体验。

    如果你对技术充满热情,欢迎加入抖音基础技术团队,让我们一起打造亿级国家级APP。目前我们在上海、北京、杭州、深圳均有招聘需求。内部推荐可联系邮箱:liyao.ryan@bytedance.com,邮件主题:姓名-工作年限-抖音-基础技术-iOS/Android。

    站内大部分资源收集于网络,若侵犯了您的合法权益,请联系我们删除!
    欧资源网 » 字节跳动抖音研发工具链面临的挑战与问题(组图)

    常见问题FAQ

    免费下载或者VIP会员专享资源能否直接商用?
    本站所有资源版权均属于原作者所有,这里所提供资源均只能用于参考学习用,请勿直接商用。若由于商用引起版权纠纷,一切责任均由使用者承担。更多说明请参考 VIP介绍。
    提示下载完但解压或打开不了?
    最常见的情况是下载不完整: 可对比下载完压缩包的与网盘上的容量,若小于网盘提示的容量则是这个原因。这是浏览器下载的bug,建议用百度网盘软件或迅雷下载。若排除这种情况,可在对应资源底部留言,或 联络我们.。
    找不到素材资源介绍文章里的示例图片?
    对于PPT,KEY,Mockups,APP,网页模版等类型的素材,文章内用于介绍的图片通常并不包含在对应可供下载素材包内。这些相关商业图片需另外购买,且本站不负责(也没有办法)找到出处。 同样地一些字体文件也是这种情况,但部分素材会在素材包内有一份字体下载链接清单。
    欧资源网
    一个高级程序员模板开发平台

    发表评论