成为架构师是每个程序员的梦想，但并不意味着把编程做好就能够自然而然的成为一个架构师，优秀的程序员和架构师之间还有一个明显的鸿沟需要跨越，这个鸿沟就是“不确定性”
架构设计并没有像编程语言那样的语法约束，更多的时候是面多多种可能时的“选择”
例如：
- 选先进的技术还是团队熟悉的技术？先进的出问题怎么办？熟悉的后续技术演化困难怎么办？
- 用Angular还是React，一个很强大一个更灵活
- MySQL还是MongoDB？
- 淘宝的电商架构咳哟简单的照搬么？
- 等等
但存在共性原则：合适原则、简单原则、演化原则
合适原则
合适优于业界领先。
优秀人才的技术情节导致各种以先进技术主导的创业失败，原因有：
- 将军难打无兵之仗（人数）
- 罗马不是一天建成的（积累）
- 冰山下面才是关键（业务）
所以真正的优秀架构都是在企业当前人力、条件、业务等各种约束下设计出来的。BAT的架构师到小公司没有了大公司的资源、平台、积累和业务，只照搬大公司的做法和技术即会失败！
简单原则
简单优于复杂。
软件领域复杂度体现两个方面：
1、结构的复杂性
- 组成复杂系统的组件数量更多
- 同事这些组件之间的关系也更加复杂
- 组件增多整体出现鼓掌的概率增加，可用性下降
- 某个组件改动会影响关联的所有组件
- 定位复杂系统的问题比简单系统更加困难
2、逻辑的复杂性
- 单组件承担功能过多，导致逻辑复杂度升高
- 后续的功能修改会影响很大
- 使用了复杂的算法难以实现修改和问题解决
如果简单和复杂的都能满足需求，最好选择简单的方案！
演化原则
演化优于一步到位。
软件架构同建筑架构相似，但建筑不可变，软件可变。
例如：Windows的演化、Android的发展。
软件架构类似于大自然“设计”的一个生物，通过演化适应环境，逐步变得强大。
- 首先满足当前需要
- 不断迭代保留，不断完善
- 业务变化时，架构扩展、重构、甚至重写。
不要贪大求全，分析清楚自身业务特点，快速落地，不断完善演化。