应用失败-回顾

任何应用程序工程师都会告诉您，如果您无法远程解决问题并必须向商店发布更新以修复该问题，则最糟糕的事情是应用程序崩溃。

这是我们本周发生的事情，我认为解决这个问题，原因和我们可以从中学到什么很重要。

我们依靠来自Facebook和Twitter的社交API来进行社交共享计数器，评论和共享工具。

昨天，一枚未经改动的隐藏式代码炸弹爆炸了。 Facebook已弃用并删除了我们用于显示文章的社会统计和检索图形ID所需的Facebook API之一。这导致我们的应用程序无法检索计数，而不仅仅是一个问题，除了我们无法优雅地处理丢失的数据并导致应用程序崩溃外，这是不可恢复的。

2015年12月，我们发布了应用程序V1.0，作为一家成长中的公司，我们在工程团队中没有足够的资源或能力来构建iOS应用程序，因此我们将其外包。

不幸的是，当我们将应用程序带到内部时，代码处于不良状态，没有单元测试，很少的文档，并且在过去的几个月中我们一直在努力改善应用程序中的代码味道，我们只是没有最终会爆炸并以致命方式影响我们用户的代码。

自V1.0以来，触发炸弹的代码一直处于休眠状态，因此我们应用程序的每个版本都变得无法使用，用户将打开我们的应用程序，尝试阅读文章（该文章将立即加载）然后崩溃。

在当前版本存储的24小时内，有89％的用户受到了影响，我们收到的评论和电子邮件都很差。

眼下的解决方案是应对Facebook的空洞回应，这意味着我们可以相对较快地将问题修复到商店中，但将受到苹果评论之神的摆布。填写快速审查表后，这是一个“静观其变”的问题。

尽管我们对发布的修复程序充满信心，但重要的是要检查代码并确定如何重新引入不可用的股数和注释。恢复功能后，我们提交了单独的版本，与其重新构建木板并冒沉船的风险，不如将其快速塞入孔内。

在将插件提交给Apple的8小时后，我们设法恢复了对我们内容的访问权限，从而避免了致命的崩溃。

提交重建的共享和评论功能24小时后，就可以发布了。

总而言之，我们设法在36小时（36小时）内找到，修复和恢复功能。

从此类事件中学习很重要，狗屎会发生，从中学习将有助于防止同一狗屎发生两次。

我们正在审查所有底层的第三方API，并在可能的情况下确保我们已收到有关这些API更改的通知，并在其中可以远程删除，合并或抽象API功能；这将确保我们可以远程处理更改并避免发生类似事件。

它已经在我们的视野中，但是我们将添加一个热修复程序解决方案，该解决方案将使我们能够修补未来的问题，然后发布相关的修复程序。

我们可以学到的最大的一课是进行定期的完整代码审查，我们反复进行审查，但是随着时间的推移，整个代码库都需要进行检查。

您的应用程序是否发生过类似的问题？您是如何解决它的？您学到了什么？我希望收到您的来信。