我正在尝试理解的

Source: Dev.to

背景

我是一名中级软件工程师，职业生涯起步于构建 Web 应用，主要使用 Ruby on Rails。随着时间的推移，我在构建 SaaS 产品时使用了其他框架和前端技术。

框架帮助我快速迭代：它们提供了清晰的结构、熟悉的模式，以及一种我知道自己在做什么的感觉。大部分复杂性都被框架帮我处理了，我也几乎没有去质疑它们。

意识的提升

某个时刻，这种感觉已经不再足够。虽然我构建的系统能够运行，但在某些时刻，我对它们的理解显得很浅薄。我可以解释代码，却不一定能说明系统运行时到底发生了什么。我习惯用请求、响应、控制器和服务来思考问题，但对重试、后台任务、部分失败，或者系统在重启后表现不同的原因却不太擅长解释。

当生产环境出现问题时，答案往往在我平时不关注的系统部分。现代框架悄悄地帮我们省掉了很多工作——这并不是坏事，但它们也隐藏了软件随时间实际运行的方式。如果你从不去看看幕后的细节，就永远无法真正建立直觉。

软件的未来方向

我开始更多地思考软件的未来。未来似乎不会仅仅是请求‑响应、即时反馈和完美的运行环境。越来越多的系统会在存在延迟、故障常态化、以及事件不一定立即或按预期顺序发生的环境中运行。

这些关注点既出现在关于分布式系统的实际讨论中，也出现在关于自主系统或太空探索的设想性对话里。作为《星球大战》的粉丝，我常想到去月球或火星旅行、甚至有人类在那儿定居的设想。但我们很少停下来思考软件在那种环境下到底会怎样运行：当消息被延迟、连接中断、故障成为常态时，系统如何通信。

开始学习日志

我意识到我并不想放弃已经使用的工具，也不想远离 Web 开发和框架。我想了解它们到底抽象掉了什么。

于是，这将是一系列日志的开始——不是教程系列，也不是“一夜之间成为系统工程师”的指南。这是学习日志，一个记录我在尝试更好地理解软件——作为一种随时间运行、受约束、并在故障和不确定性中工作的事物——时思考变化的地方。

有时帖子会是简短的笔记，有时是更长的反思，有时是对之前自认为正确的想法的纠正。我并不懂得全部，但我想比现在了解得更多，并且希望以谨慎、诚实的方式，尽可能贴近软件在真实世界中的行为来进行学习。