From 4e3c8dae58cbefebc9fd81f6df1daffb3a56eb46 Mon Sep 17 00:00:00 2001
From: fanbaoying <baoying.fan@qq.com>
Date: Sun, 4 Sep 2022 16:23:53 +0800
Subject: [PATCH] Update

---
 .DS_Store                                     | Bin 8196 -> 8196 bytes
 README.md                                     |   2 +
 resource/.DS_Store                            | Bin 8196 -> 8196 bytes
 ...57\345\277\205\351\241\273\347\232\204.md" |  98 ++++++++++++++++++
 4 files changed, 100 insertions(+)
 create mode 100644 "resource/\351\241\271\347\233\256\344\270\255\347\254\254\344\270\211\346\226\271\345\272\223\345\271\266\344\270\215\346\230\257\345\277\205\351\241\273\347\232\204.md"

diff --git a/.DS_Store b/.DS_Store
index 6553b4bcd63f0c40bfc3656c0c40fa65a9593d94..0bae2e8522d7436113a4504ac3e3350d971141ed 100644
GIT binary patch
delta 104
zcmZp1XmOa}&nUDpU^hRb&}1Hge8wG<YXl0pC911Uj4X8&jEoE>{}hmB?3!#TEYH}z
p*;Fux5m||aj)JLy1+tRKAB9CG=L#>MSR%Yxo#z4bW_F3c>;Q2SAX@+c

delta 194
zcmZp1XmOa}&nUbxU^hRb@MIo=e8!!V7YY^fNLE)HS{j+^DCioQPnH#yX6&A9DJ;*}
zv)M#2hmmnRNR65}P>qR+j)Iv*t&T#qrLl#Mf~kRVZ7nB<sItCwP<(byZeD&TSYOxV
zKp~OIxx&khW&G<)H5e2af*HygG8xhsN*F>JJQ)<qT7Y7%42cZs45<u7K(;%O%w$Mm
iC}yaetS=<WEz7{b$oC%%HW$cDVV>B)vzcAuFFOD?bT&l*

diff --git a/README.md b/README.md
index 8a3abcd..0602893 100644
--- a/README.md
+++ b/README.md
@@ -12,6 +12,8 @@
 
 ## 最新
 
+[Swift 周报 第十二期](https://mp.weixin.qq.com/s/IXP8PNT4aoCnyB-V2qMY_Q)
+
 [使用 SwiftUI 的 Eager Grids](https://mp.weixin.qq.com/s/Ew8SBz-81NQ-dJFONmadVA)
 
 [解决 Flutter 引起的 iOS 内存崩溃问题](https://mp.weixin.qq.com/s/exaRmdUnpzSvlJ2BGSODgw)
diff --git a/resource/.DS_Store b/resource/.DS_Store
index fcfd029cea7743c1ae1964c33e480dc3ad1ca45d..6af4eeb52eda0f8f5182bc8d842a065e66696f6d 100644
GIT binary patch
delta 347
zcmZp1XmOa}&&a<qU^hP_|70Ek9RUUghV?)^?>`tYFiiFkFaZiO{zMV%5ikP^GNq#k
zUIJ@pltmHb6Epy6??w^y6LbLyf>i3kEm|b#1QZ0@ju8AJ=myh{5cCpq01AR_M+nXm
z0=bjH5yi}VLRKK{AjczA-V@T>9473*=nqv6_bZSuFr%{Uou6*Cjvr_0&bY~OWq!PA
v`te6+RF}0d=rQCnq<H4!Cnx3PCxO&L^fU57y|DS6j2QF82A<9A5`WnN<za*Y

delta 284
zcmZp1XmOa}&&aniU^hP_-((&E9fAL7V6umR38r9=fElLXC2ZRH1Pw4%`U$#V3N8|K
z!W8@>=!PliCFFo9I7<kNJMRfuVXC|*q_;Ut*nts4X7hTPQ09pZJe%1i{;~rAhPm4X

diff --git "a/resource/\351\241\271\347\233\256\344\270\255\347\254\254\344\270\211\346\226\271\345\272\223\345\271\266\344\270\215\346\230\257\345\277\205\351\241\273\347\232\204.md" "b/resource/\351\241\271\347\233\256\344\270\255\347\254\254\344\270\211\346\226\271\345\272\223\345\271\266\344\270\215\346\230\257\345\277\205\351\241\273\347\232\204.md"
new file mode 100644
index 0000000..b1f76f9
--- /dev/null
+++ "b/resource/\351\241\271\347\233\256\344\270\255\347\254\254\344\270\211\346\226\271\345\272\223\345\271\266\344\270\215\346\230\257\345\277\205\351\241\273\347\232\204.md"
@@ -0,0 +1,98 @@
+
+## 前言
+
+我在Lyft的八年间，很多产品经理以及工程师经常想往我们 app 里添加第三方库。有时候集成一个特定的库（比如 **PayPal**）是必须的，有时候是避免去开发一些非常复杂的功能，有时候仅仅只是避免c重复造轮子。
+
+虽然这些都是合理的考量，但使用第三方库的风险和相关成本往往被忽视或误解。在某些情况下，风险是值得的，但是在决定冒险之前，首先要能够明确的定义风险。为了使风险评估更加的透明和一致，我们制定了一个流程来衡量我们将其集成到app有多大的风险。
+
+## 风险
+
+大多数大型组织，包括我们，都有某种形式的代码审查，作为开发实践的一部分。对这些团队来说，添加一个第三方库就相当于添加了一堆由不属于团队成员开发，未经审查的代码。这破坏了团队一直坚持的代码审查原则，交付了质量未知的代码。这给app的运行方式以及长期开发带来了风险，对于大型团队而言，更是对整体业务带来了风险。
+
+### 运行时风险
+
+库代码通常来说，对于系统资源，和app拥有相同级别的访问权限，但它们不一定应用团队为管理这些资源而制定的最佳实践。这意味着它们可以在没有限制的情况下访问磁盘，网络，内存，CPU等等，因此，它们可以（过度）将文件写入磁盘，使用未优化的代码占用内存或CPU，导致死锁或主线程延迟，下载（和上传！）大量数据等等。更糟糕的是他们会导致崩溃，甚至[崩溃循环](https://www.theverge.com/2020/5/7/21250689/facebook-sdk-bug-ios-app-crash-apple-spotify-venmo-tiktok-tinder)。[两次](https://github.com/facebook/facebook-ios-sdk/issues/1427)。
+
+其中许多情况直到 app 已经上架才被发现，在这种情况下，修复它需要创建一个新版本，并通过审核，这通常需要大量时间和成本。这种风险可以通过一个变量控制是否调用来进行一定程度的控制，但是这种方法也并非万无一失（看下文）。
+
+### 开发风险
+
+引用一个同事的话：“每一行代码都是一种负担”，对不是你自己写的代码而言，这句话更甚。库在适配新技术或API时可能很慢，这阻碍了代码开发，或者太快，导致开发的版本过高。
+
+库在采用新技术或API时可能很慢，阻碍了代码库，或者太快，导致部署目标太高。每当 Apple 和 Google 每年发布一个新 OS 版本时，他们通常要求开发人员根据SDK的变化更新代码，库开发人员也必须这样做。这需要协调一致的努力、优先事项的一致性以及及时完成工作的能力。
+
+随着移动平台的不断变化，以及团队（成员）也不是一成不变，这将会成为一个持续不断的风险。当被集成的库不存在了，而库又需要更新时，会花很多时间来决定谁来做。事实证明一旦一个库存在，就很少也很难被移除，因此我们将其视为长期维护成本。
+
+### 商业风险
+
+如同我上面所说，现代的操作系统并没有对 app 代码和库代码进行区分，因此除了系统资源之外，它们还可以访问用户信息。作为 app 的开发者，我们负责恰当的使用这部分信息，也需要为任何第三方库负责。
+
+如果用户给了 Lyft app 地理位置授权，任何第三方库也将自动得获得授权。他们可以将那些（地理位置）数据上传到自己服务器，竞对服务器，或者谁知道还有什么地方。当一个库需要我们没有的权限时，那问题就更大了。
+
+同样，一个系统的安全取决于其最薄弱的环节，但如果其中包含未经审核的代码，那么你就不知道它到底有多安全。你精心设计的安全编码实践可能会被一个行为不当的库所破坏。苹果和谷歌实施的任何政策都是如此，例如“你不得对用户追踪”。
+
+## 减少风险
+
+当对一个库（是否）进行使用评估时，我们首先要问几个问题，以了解对库的需求。
+
+### 我们内部能做么？
+
+有时候我们只需要简单的粘贴复制真正需要的部分。在更复杂的场景中，库与自定义后端通信，我们对该API进行了逆向，并自己构建了一个迷你SDK（同样，只构建了我们需要的部分）。在90%的情况下，这是首选，但在与非常特定的供应商或需求集成时并不总是可行。
+
+### 有多少用户从该库中受益？
+
+在一种情况下，我们正在考虑添加一个风险很大的库（根据下面的标准），旨在为一小部分用户提供服务，同时将我们的所有用户都暴露在该库中。 对于我们认为会从中受益的一小部分客户，我们冒了为我们所有用户带来问题的风险。
+
+### 这个库有什么传递依赖？
+
+我们还需要评估库的所有依赖项的以下标准。
+
+### 退出标准是什么？
+
+如果集成成功，是否有办法将其转移到内部？ 如果不成功，是否有办法删除？
+
+## 评价标准
+
+如果此时团队仍然希望集成库，我们要求他们根据一组标准对库进行“评分”。下面的列表并不全面，但应该能很好地说明我们希望看到的。
+
+### 阻断标准
+
+这些标准将阻止我们从技术上或者公司政策上集成此库，在进行下一步之前，我们必须解决：
+
+**过高的** **deployment target/target SDKs。** 我们支持过去4年主流的操作系统（版本），所以第三方库至少也需要支持一样多。
+
+**许可证不正确/缺失。** 我们将许可文件与应用捆绑在一起，以确保我们可以合法使用代码并将其归属于许可持有人。
+
+**没有冲突的传递依赖关系。** 一个库不能有一个我们已经包含但版本不同的传递依赖项。
+
+**不显示它自己的 UI 。** 我们非常小心地使我们的产品看起来尽可能统一，定制用户界面对此不利。
+
+**它不使用私有 API 。** 我们不愿意冒 app 因使用私有 API 而被拒绝的风险。
+
+### 主要关注点
+
+**闭源。** 访问源代码意味着我们可以选择我们想要包含的库的哪些部分，以及如何将该源代码与应用程序的其余部分捆绑在一起。 对于我们来说，一个封闭源代码的二进制发行版更难集成。
+
+**编译时有警告。** 我们启用了“警告视为错误”，具有编译警告的库是库整体质量（下降）的良好指示。
+
+**糟糕的文档。** 我们希望有高质量的内联文档，外部”如何使用“文档，以及有意义的更新日志。
+
+**二进制体积。** 这个库有多大？一些库提供了很多功能，而我们只需要其中的一小部分。尤其是在没有访问源码权限的情况下，这通常是一个全有或全无的情况。
+
+**外部的网络流量。** 与我们无法控制的上游服务器/端点通信的库可能会在服务器关闭、错误数据被发回等时关闭整个应用程序。这也与我上面提到的隐私问题相同。
+
+**技术支持。** 当事情不能正常工作时，我们需要能够报告/上报问题，并在合理的时间内解决问题。开源项目通常由志愿者维护，也很难有一个时间线，但至少我们可以自己进行修改。这在闭源项目是不可能的。
+
+**无法禁用。** 虽然大多数库特别要求我们初始化它，但有些库在实例化时更“主动”，并且在我们不调用它的情况下可以自己执行工作。这意味着当库导致问题时，我们无法通过功能变量或其他机制将其关闭。
+
+我们为所有这些（和其他一些）标准分配了点数，并要求工程师为他们想要集成的库汇总这些点数。虽然默认情况下，低分数并不难被拒绝，但我们通常会要求更多的理由来继续前进。
+
+## 最后
+
+虽然这个过程看起来非常严格，在许多情况下，潜在风险是假设的，但我们有我在这篇博文中描述的每个场景的实际例子。将评估记录下来并公开，也有助于将相对风险传达给不熟悉移动平台工作方式的人，并证明我们没有随意评估风险。
+
+此外，我不想声称每一个第三方库本质上都是坏的。事实上，我们在Lyft使用了很多：`RxSwift`和`RxJava`、`Bugsnag`的`SDK`、`Google Maps`、`Tensorflow`，以及一些较小的用于非常特定的用例。但所有这些要么都经过了充分审查，要么我们已经决定风险值得收益，同时对这些风险和收益的真正含义有了清晰的认识。
+
+最后，作为一个专业开发人员提示：始终在库的`API`之上创建自己的抽象，不要直接调用它们的`API`。这使得将来替换（或删除）底层库更加容易，再次减轻了与长期开发相关的一些风险。
+
+> [译自：Third-party libraries are no party at all](https://scottberrevoets.com/2022/07/15/third-party-libraries-are-no-party-at-all/?utm_source=swiftlee&utm_medium=swiftlee_weekly&utm_campaign=issue_124)
\ No newline at end of file