……请注意，这种“状态管理”以及过去十年来更加活跃的喧嚣，对我来说从来都不是一个特别有用而需要命名的问题。20多年的平庸职业生涯中，我仍然不明白它是什么，为什么会出现这个问题。也许这就是为什么我的职业生涯很平庸？生活在这样一个充满谎言的国家也无济于事。另一方面，一旦有计划和决心，我可以在下周就做出可以工作的最小可行产品。（不，不是 PHP。）我认为喧嚣的根源在于软件变得越来越难以控制的底层，因此有很多自我强加的状态，而业务本身甚至都没有意识到这些状态，这些状态变成了每行代码的常规内容，很容易遇到，但很难记录或向外部人员解释。状态属于业务，而不是你的控制范围，其他所有状态都是寄生的。在程序中一对一地映射业务状态，可以让一切变得简单、容易更改、容易扩展。这通常是命令式的，有时是声明式的（这就是编程出现的地方），从不是函数式的。寄生状态应该被掩盖起来。……
源讨论所有编程哲学都是关于状态的原帖 238 条评论 · 导入时统计把你的经验，加入这段讨论。
程序的文本无法显示内存中的内容，也无法显示连接到机器的设备正在做什么。你希望如果你在脑海中运行程序，你可以可靠地猜测——但通常你会犯错误。 控制“状态”意味着努力让世界尽可能接近你程序的文本，以避免出错。
完整原文思考状态帮助我编写更好的代码。如果一个项目的代码库足够小，我可以枚举所有状态以及状态如何转换为其他状态，我可以编写出非常稳定的代码，它可以无限运行。这非常令人满意。我认为从这一点出发的下一步是TLA+（我还没有尝试过）。
完整原文对于很多中小型业务软件来说，状态通常主要由一个中心的、唯一的数据源数据库来管理，业务逻辑会应用到这个数据库上；在这种情况下，你处理“请求”状态（无论是网络请求还是GUI/TUI请求接口）所采用的范式并不那么重要。
完整原文你的生态系统越偏向网络化和多CPU，这个问题就越突出。我觉得这篇文章相当平庸和显而易见。状态本身就是‘如何’和‘什么’。
完整原文也许你只是倾向于用合理的方式来处理它？ 有一些事情（我认为）是很难的，而且与状态管理有关，以下是一些非排他性的例子： - 一般而言，GUI需要管理的状态更多，尤其是交互性越强，需要管理的状态就越多。 - 缓存（在任何层级）都是一种状态。你需要了解数据何时变化、谁改变了它，以及当你要关注它时，哪些缓存部分会受到影响等等。 - 内存和磁盘分配是状态。你需要了解你的资源是什么，以及何时释放它们。你可能会使用锁来确保数据不会被破坏。在更高层次上，你可能会有授权模型来限制访问。 - TCP 是有状态的。当连接失败或中断时你该怎么办？你是否要存储/缓冲消息以便稍后处理？这对接收方意味着什么？ - SQL 数据…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。