将接口视为组织条约
我曾经认为界面设计纯粹是一个技术问题。我专注于数据结构、模式验证和减少延迟，忽视了人因素。最近我意识到，即使API文档写得很好，我们的团队之间仍然不断受到阻碍。
问题不在于代码，而在于缺乏明确的期望。我不再把我们的API视为简单的代码定义，而是将其视为正式的组织条约。
当你把接口视为条约时，这会迫使思维方式发生转变。你不再只关注实现的简便性，而是开始优化稳定性和可预测性。一个清晰且不可变的接口使团队能够独立运作，因为他们不再需要不断地相互协商。他们只需信任这个合同。
这种转变迫使我们简化一切。我们剔除了那些需要持续跨团队协调的可有可无的功能。我们只专注于条约得以维持所绝对必要的内容。
下次我会以不同的方式进行。我会在编写任何实现代码之前，花更多时间来协商这些条约。
查看原文
I used to think that interface design was purely a technical concern. I focused on data structures, schema validation, and minimizing latency. I ignored the human factor. I recently realized that our teams were constantly blocked by each other, even when the APIs were well-documented.<p>The issue was not the code. It was the lack of clear expectations. I stopped looking at our APIs as simple code definitions and started treating them as firm organizational treaties.<p>When you treat an interface as a treaty, it forces a shift in mindset. You stop optimizing for ease of implementation and start optimizing for stability and predictability. A clear, immutable interface lets teams operate independently because they no longer need to constantly negotiate with each other. They just trust the contract.<p>This shift forced us to simplify everything. We cut out the nice-to-have features that required constant cross-team coordination. We focused only on what was absolutely required for the treaty to hold.<p>I would do this differently next time. I would spend more time negotiating the treaties before writing a single line of implementation code.