[Mobile翻译]MobileAtScale-39个工程挑战-前言

307 阅读8分钟

image.png

大规模构建移动应用程序

39项工程挑战

Copyright © 2021 by Gergely Orosz

保留所有权利。

未经版权所有者书面许可,不得以任何方式复制或使用本书的任何部分,但在书评中使用引文的情况除外。欲了解更多信息,请联系:scale@pragmaticengineer.com

ISBN: 978-1-63795-844-5 (电子书) FIRST EDITION, v1.0 www.MobileAtScale.com

目录

Bitrise的前言 5

简介 6

致谢 7

关于作者 8

当事情变得简单 9

第一部分:由于移动应用的性质所带来的挑战 10

  1. 状态管理11
  2. 错误难以挽回14
  3. 旧版App的长尾效应 16
  4. Deeplinks 17
  5. 推送和后台通知18
  6. 应用程序崩溃20
  7. 离线支持24
  8. Accessibility 27
  9. CI/CD & Build Train 29
  10. 第三方库和SDK 35
  11. 设备和操作系统碎片 37
  12. 应用内购买39

第2部分:应用复杂性带来的挑战46

  1. 大型应用程序内的导航架构47
  2. 应用状态和事件驱动的变化 50
  3. Localization 53
  4. 模块化结构和依赖注入57
  5. 自动测试58
  6. 手动测试63

第三部分:大型工程团队带来的挑战67

  1. 计划和决策68
  2. 构建避免踩到对方脚趾的方法 70
  3. 跨越多个应用程序的共享架构72
  4. 大型工程团队的工具成熟度 74
  5. 扩展构建和合并时间75
  6. 移动平台库和团队77

第四部分:语言和跨平台方法 85

  1. 采用新的语言和框架86
  2. Kotlin多平台和KMM 88
  3. 跨平台功能开发91
  4. 跨平台应用开发与本地95
  5. Web, PWA & Backend-Driven Mobile Apps 101

第五部分:由于加强你的游戏而带来的挑战105

  1. Experimentation 106
  2. 特色旗帜地狱110
  3. Performance 113
  4. 分析、监控和警报118
  5. 移动随叫随到125
  6. 高级代码质量检查127
  7. 合规、隐私和安全130
  8. 客户端数据迁移133
  9. 强制升级134
  10. 应用程序大小137

关于Bitrise 145

来自Bitrise的前言

本书的想法是在Gergely Orosz开始写一篇关于构建大规模原生移动应用的复杂性的博文时产生的。尽管他在一家移动优先的公司工作,但他觉得他的大多数领导层并不完全了解移动开发有多大的挑战性--特别是当涉及到数百万人使用的应用程序。

在对他的内容产生了令人难以置信的兴趣,并且草案得到了积极的回应之后,他的项目变得越来越大。最初的博文变成了一本书--作为官方赞助商,我们很高兴能与你分享。

这本书和Bitrise今天的存在都是出于同样的原因:因为构建移动应用程序是独特的挑战。几年前,Bitrise 的三位创始人亲身经历了

移动工程的日常斗争,由于缺乏移动专用的工具集。

我们很快决定建立我们自己的解决方案,这就是我们如何走到今天的。

当我们第一次接触到Gergely的项目时,我们立即知道它将是特别的。我们对这本书有如此强烈的感觉是有原因的:它将帮助移动工程团队更好地执行,通过挖掘行业内一些最聪明的人几十年的经验。它不仅为任何创建移动应用的人提供了一个缺失的指南,而且也是产品经理、网络和后台团队以及想深入了解移动开发幕后运作的学生的必读之作。

本版撰稿人:

  • Moataz Nabil, 开发者倡导者
  • Kevin Toms, 开发者倡导者
  • Nóra Bézi, 内容策略师
  • Dóra Sirály, 平面设计师
  • Hendrik Haandrikman, 发展副总裁

-- 来自Bitrise的

介绍

我注意到,虽然人们对后端和分布式系统的挑战有很多赞赏,但对为什么移动开发在大规模进行时很难有共鸣。 建立一个为数百万客户提供服务的后端系统意味着建立高度可扩展的系统和可靠地运行这些系统。但同样系统的移动客户端呢?

大多数没有建立过移动应用程序的工程师认为移动应用程序是一个简单的门面,需要较少的工程努力来建立和运行。在建立了这两种类型的系统之后,我可以说情况并非如此。在建立大型的、原生的、移动的应用程序方面有很多深度,但不在这个领域的人往往没有什么好奇心。产品经理、商业利益相关者,甚至非原生移动工程师,都很少理解为什么在移动端出货 "需要这么长时间"。

本书收集了工程师们在大规模构建iOS和Android应用程序时所面临的挑战

所谓规模,我指的是用户数量达到数百万,并由大型工程团队构建。这些团队不断推出功能,但仍要确保应用可靠地运行,并以一种高性能的方式运行。

本书是对当前大型原生移动团队所使用的行业实践的总结,并指出了一些解决这些问题的常见方法。本书所传达的大部分经验来自于我在Uber工作时的经历,当时我在一个复杂而广泛使用的应用中工作。在类似的复杂环境中工作的其他30多位工程师也提供了他们的见解;他们是在Twitter、亚马逊、Flipkart、Square、Capital One等公司开发应用的工程师。

其他公司的工程师。

我希望这本书能够帮助非移动工程师对移动工程师所面临的挑战和权衡的类型产生共鸣,并成为后端、Web和移动团队之间的对话起点。

鸣谢

本书的编写得到了30多位移动工程师和经理的大力支持和评论,其中许多人都是各自领域的资深专家。非常感谢他们所有人。如果你在Twitter上,我建议你关注他们。

感谢Emmanuel Goossaert撰写的第10章:第三方库和SDK

特别感谢本书的编辑,Dominic GoverBest English Copy帮助创造了一本令人愉快的书。

关于作者!

image.png

Gergely自2010年以来一直在建立原生移动应用程序,从Windows Phone开始,后来在iOS和Android。从一个人的应用程序开始,他与Skyscanner的小团队合作,到Uber的数百名工程师在同一个代码库工作。

在Uber,他参与了RiderDriver应用程序的重写,这两个项目都有数百名移动工程师参与。他所负责的应用程序在60多个国家拥有超过1亿的月度用户,其中有几个功能是为单一国家或地区建立的。

你可以在The Pragmatic Engineer Blog上阅读他的更多文章,在LinkedInTwitterYouTube上联系他,并通过scale@pragmaticengineer.com。

当事情简单时

让我们来谈谈房间里的大象:经常假设客户端开发很简单。假设最大的复杂性在于确保事情在各种移动设备上看起来不错。

当你要解决的问题很简单,而且范围很小的时候,就很容易提出简单的解决方案。 当你用一个小团队和很少的用户建立一个功能有限的应用程序时,你的移动应用程序不应该是复杂的。你的后台可能会很容易理解。你的网站将是一个不费吹灰之力的问题。你可以使用现有的库、模板和各种捷径,将工作方案落实到位。

一旦你的规模扩大--客户、工程师、代码库和功能--一切都会变得更加复杂、更加臃肿,并且更难理解和修改,包括移动代码库。这就是我们在本书中关注的部分;当事情变得复杂时。当你的应用程序变得庞大时,没有银弹可以神奇地解决你所有的痛点,只有艰难的权衡。

本书从你的应用程序不再简单的那一刻开始讲起。


www.deepl.com 翻译