人人都是架构师
背景
发展阶段需要“人人都是架构师”，每个人的成长需要“架构师思维”。
- 商业模式探索的初期，需要快速迭代、验证模式，所以纵向发展是效率最高的模式。
- 在当下的快速发展期，在一定的确定性下，提升系统的效率比单点优化更加重要。
补充：纵向发展：或者叫做纵深发展，指在某一个方向做到Master级别，一骑绝尘。
定义
“架构师”不是头衔，而是一种能力。每个工程师都应该具备一定的架构能力。
每个人在编程中，小到开发一个函数，大到设计一个模块、搭建一个系统，都可以成为架构师。
让每个人写出的代码有更长的生命力，更好的适应性，服务更多的业务和用户。
补充：只要是一种能力，就有训练和培养的方法，并且可以通过不断地练习和重复加强记忆。
关键要素
前提：好的架构一定是简洁的，而不是复杂的。
- 系统观： 洞察系统的本质要素，厘清要素之间的关系，以及制定相应策略的能力。高内聚、低耦合的架构能力，将一个大的系统切分成多个低耦合的子模块的能力。从立烟囱一般的需求交付到合理的模块设计，从仅仅考虑眼前的应对到面向未来的设计。
- 从局部到整体： 以工程思维 全面理解业务需求。基于技术领域模型和业务特征做抽象简化，在可预见的周期内扩展广度和深度。在系统生命周期内不断演进。洞察细节，整体设计。考虑差异性之前，要最大可能性地找到共性。
- 评价指标： 驱动自身的迭代。做完一个内容，不是结束而是意味着自身架构设计迭代的开始。不是开发一个项目，而是迭代一个系统。
- 成长思维： 面向所有人。对自己工程/算法的基本能力上有高要求。有改变的决心和有效的方法，保持学习，突破自我。
建议
- 架构设计的准则与共识。Leader要和团队深度交流，不遗余力的培养成员的架构能力，不断探讨系统的边界、模型抽象、模块设计、流程抽象是否合理，设计背后的思考与理念是什么，不断碰撞与讨论，leader和团队都会有所成长。
- Hands-on 写代码 Zoom in 去验证。Leader要hands-on coding，参与核心业务逻辑的编码工作，深入代码细节中去做架构。无谓的讨论是低效的，验证架构师否合理的方式，就是结合业务场景，写代码去验证，设计是否合理，是否优雅，在coding过程中便能获得很好的反馈。
- 流程机制。嵌入到流程机制，需求在实现前必须有技术方案、架构设计讨论、文档产出。从边界不清，责任模糊的认为复杂，到通过结构设计，流程清晰带来的“天然简单”。
补充： 在设计时，询问自己为什么要这样设计，是考虑了什么优点，缺点在什么地方；有没有其他方案能尝试，评估过程和结论是什么；此方法实现的过程是否合理，有无隐患。
