最近几年，接触了很多团队，特别是创业的技术团队，大家容易犯的一个错误就是有些形而上学，而没有真正了解背后的真正原因。
比方说，大家对「快速迭代」有共识，没有团队会反对执行快速迭代，但也有严重的误解。事实上，很多团队没有做好快速迭代的真正原因，并不是工程师能力差或者不愿意快速迭代，而是没有一个可以支持快速迭代的架构和基础工具。想快速迭代，对架构设计的要求是比平常更高的，这里说的不是高并发、高可用的架构，而是支持高迭代的架构。
在一个产品的初期，很多技术管理者思考的是高可用，其实完全错了，而是应该思考快速迭代的框架，为什么？因为产品的方向和细节刚开始是很难想明白的，包括大家正在用的微信，龙哥当时也没完全想明白。另外，更别说刚开始产品就没有几个用户。
有朋友会跳出来，高可用和快速迭代矛盾吗？可以两者兼有嘛。但实际上，我们就是要分出「主要」:
快速迭代的架构「主要」是为了「开发阶段」。高可用的架构是「主要」为了「增长」阶段，高扩展的架构是「主要」为了「运维阶段」。这几者是不同的。
我喜欢用「维度」来思考框架：无论是技术还是业务框架亦是如此。维度的思考方式可以让我，在一段时间只关注一个方面，避免分心，可以有最大的思考成果，能最大化的实现业务目标。在不同维度下，我会进一步看，是否还有必要进行细分。
下车了，昨天忘记提前买票了，今天只买到站票，反而让我加速写完。