作为一名 Android 开发者,开发一款支持超过 10 万用户的流行汇款应用程序,我的工作是确保该应用程序顺利运行并及时解决所有报告的问题。我习惯于偶尔从报告应用程序问题的用户那里获得支持票。但有一天,我收到了大量无法通过该应用向特定地区汇款的人寄来的罚单。这尤其令人担忧,因为它临近假期,很多人依靠我们的应用程序向他们的亲人汇款。
我知道我必须尽快查明这个问题的真相。于是我求助于夏洛克·福尔摩斯的智慧,开始了我的侦探工作。但我很快发现,解决这个问题绝非易事。要找出错误的根本原因并让应用程序再次正常运行,需要我所有的侦探技能以及一点点运气。
我首先在自己的设备上重现了这个问题,试图向受影响的地区汇款。果不其然,应用程序卡住了,并显示一条错误消息,提示“交易失败,请稍后重试。”我尝试在 Android Studio 中使用分析器来查看是否存在任何可能导致问题的性能问题。没有骰子;应用程序按预期工作。
我迅速检查了日志,看是否有任何信息可以帮助我了解发生了什么。不幸的是,日志不是很有帮助。他们显示该应用程序正在发出通常的网络请求,但没有迹象表明是什么导致了问题。然而,似乎每次我们尝试向transactions
端点发出POST
请求时都会发生错误,但仅限于该特定区域。似乎不管我尝试了什么;我似乎无法更接近解开这个谜团。
接下来,我提取了最新的代码并检查了生产分支,看看是否有任何最近的提交可能与手头的问题相关。我还尝试使用 Postman 提出个别请求,并注意到一些奇怪的事情。该请求返回了400
的响应代码,这意味着这是一个错误的请求;这通常意味着客户端没有发送后端所需的所有信息。但是,它未能返回一个有意义的错误,详细说明请求中缺少哪些数据。鉴于此请求之前有效,看来问题出在服务器端。
为了检验这一理论,我使用了debugger
来更深入地研究代码。我在代码中的关键点设置断点并尝试再次发送交易,这次密切关注幕后发生的事情。我检查了请求是否包含后端所需的所有必要数据,甚至注销了请求和响应。 las,一切都如预期的那样,但我仍然收到 Bad request 错误。
当我继续调查时,我忍不住觉得自己错过了什么。看起来这个问题应该有一个明显的解释,但无论我怎么找,我都找不到。我可能想嘲笑我,我自己的莫里亚蒂,未解决的错误。
就在我开始失去希望的时候,我有了一个主意。我记得在问题开始前两周,后端团队推出了应用程序服务器端代码的更新。可能是更新导致了问题吗?
我联系了 Slack 上的后端开发人员,看看他们是否对这个问题有任何见解。他们告诉我他们最近推出了服务器端代码的更新,但他们不确定这是否与我遇到的问题有关。他们目前忙于解决另一个问题,只能稍后再调查我的问题。他们提到更新是逐步推出的,最初只有一小部分用户收到。由于一项新政策,我们的推出现在分阶段进行,用户将在两周内收到。会不会是更新只对收到它的用户造成了问题?
我快速检查了我的日志,看看更新时间与用户开始遇到问题的时间之间是否存在任何关联。果然,我找到了线索!
在与团队来回交流之后,我的理论得到了证实。该更新包括对服务器处理某些类型交易的方式的更改。事实证明,这一变化专门针对受影响地区的交易造成了问题。经过进一步调查,我发现后端现在需要在交易请求中包含一个额外的字段,该字段以前是可选的。这一变化是根据该地区的新法规做出的,但不幸的是,它仓促行事,记录不完整,也没有经过彻底测试。结果,该字段未包含在受影响区域的交易请求中,导致交易失败。
我简直不敢相信。经过我所有的侦探工作,我终于找到了错误的根本原因。花了很多像夏洛克一样的推理和一些创造性的思考,但我终于解决了丢失钱的问题。
我立即联系后端团队,让他们知道我的发现。他们得知是他们的更新导致了这个问题感到震惊,并为疏忽道歉。我们商定了一个双管齐下的解决方案。后端团队将发布一个修补程序,为现在的必填字段提供默认值,允许用户同时进行交易,而移动应用程序团队发布了我们的安卓应用程序的更新版本,会要求提供这些额外信息。
解决这个错误是一次具有挑战性和有益的经历。这让我想起了创造性思考的重要性,并且在调试问题时不要害怕尝试不同的方法。就像 Sherlock 和 Watson 之间的紧密联系一样,它也让我想起了协作和团队合作的力量——如果没有后端团队的帮助,我可能永远无法解决这个问题。
我希望这个关于我的侦探工作的故事能提醒其他开发人员时刻注意线索,永不放弃解决具有挑战性的问题。正如夏洛克·福尔摩斯曾经说过的那样,“一旦你排除了不可能的事情,剩下的无论多么不可能,都一定是真相。”考虑到这一点,我知道任何错误都可以被克服,无论一开始看起来多么棘手。