你听到过多少次这句话（或者甚至在心里默念过）？我知道我在对话中听到过。我也知道我曾对一两个产品产生过同样的疑问——嘿，这里的想法非常简单，让我们召集几个朋友一起，做同样的事情，但做得更好！
我喜欢 João 在这里提出的观点。 他提醒我们，应用程序或 SaaS 的核心用例通常和听起来一样简单。但正是缺乏“二阶思考”阻止了我们理解幕后的复杂性
- 团队人手不足，被迫做出让步了吗？
- 项目是否以瀑布式管理，导致一些想法无法进入发布版本？
- 是否有时间限制影响了项目的走向？
- 预算不足以支持某个特定功能吗？
- 团队内部是否存在不和谐？
我们看不到产品背后的许多东西。João 在解释为什么像 Uber 这样的公司需要数百名移动应用程序开发人员时，非常清楚地阐述了这一点。他们并非在那里支持最初的用例；他们的职责是解决二阶因素，并希望以尽可能降低复杂性的方式，与系统的其余部分一起扩展。
世界是混乱的。随着软件变得越来越普遍，我们将这种混乱编码为 1 和 0。但这不仅仅是这些。某些场景在软件中的编码比其数字化之前的对应物更困难。机场的实体出租车队列非常容易理解。不涉及 GPS 技术，也没有地理围栏。一个人和一辆车只能在一个地方。在数字世界中，事情变得更加混乱。
我想起了 Chris 之前写过的一篇帖子，他在帖子中 详细阐述了一个看似简单的 Twitter 功能请求
为什么我不能编辑我的推文？！Twitter 应该允许这样做。
情况相同。功能很复杂。产品也很复杂。是的，如果这个应用程序拥有某个特定功能或使用了一些流畅的框架来加快速度，那将非常棒——但总有需要考虑的上下文和二阶思考，然后再直接进入解决方案模式。再说一次，João 的表达比我更出色
很容易过度简化问题，并尝试优化我们用例的新型、更精简的技术。但是，当将其扩展到组织的其余部分时，我们开始看到巨龙。那些没有以“正确方式”构建其软件的人。整个技术栈依赖于团队因“某些原因™”而无法更新的库。很快，我们开始意识到，我们精简的方式可能无法满足大多数情况。
至少对我自己来说，直接跳入解决方案或某些结论很诱人。我们是解决问题的人，对吧？这就是我们被付钱做的事情！但这就是 João 描述的巨龙出现的地方。问题（及其答案）总是比表面上看到的要多。除非我们打败这些巨龙，否则我们就有可能做出错误的假设，并最终对看似简单的事情给出错误的答案。
一如既往，前端开发人员都很清楚。 这包括意识到二阶考虑因素。
也许这就是 90 90 规则存在的原因。感谢分享！