OOP教义的宗旨是，让软件开发过程变得更容易。 —— 《Java语言程序设计》

平台团队的主要目的应该是，让使用平台的人，减少认知负担。 —— 《AIDevOps》

软件开发（Software Development）和软件架构（Software Architecture）的区别是很模糊的。有的人会说，这两个概念没有区别，架构只是编程者开发过程的一个扩展；有的人则指出，这两个概念之间有着巨大的鸿沟，如果想要跨越，那么必须坚持概念抽象并且摆脱细节纠缠。

Well，模糊的边界会引起一个有趣的问题：我们如何从一种角色到另一种角色呢？

在软件开发过程中，有一些关键的指标用来区分“架构”和“开发”： 量级的增长、抽象层级的增长、决策重要性的增长。软件架构，是用更全局的视角、更宏大的图景来理解软件整体是如何运转的。或许，这个角度能够区分“架构”和“开发”，但并不能回答“如何从一种角色到另一种角色”，同理，它也不能回答“你是不是一个软件架构师”，“谁能做出好的软件架构”。

经验非常重要，并且你必须看的很深，想的更多。

你不会因为某次职业的晋升就突然成为一名架构师。架构师是一个角色，而不是一种等级。成为一名架构师是一个漫长的、演变的过程，你必须在这个过程中积累足够的经验和自信。

当观察其他的架构师时，你会发现他们除了都有一把年纪之外，还有许多不同的品质，比如：项目的参与度、影响力、领导力、以及特殊的职责任务。广义上，大多数项目中的软件架构能够被拆分成两块：定义架构、保证交付。

架构的定义

设计架构，顾名思义，就是厘清需求并设计系统满足它。但在实际工作中，架构并没有那么简单，取决于“你的投入程度”和“你对待自身角色的严肃程度”，它会在某个区间内波动。

• 非功能性需求的管理
  开发者一般会持续追问用户想要的功能特征，而很少问他们想要的系统品质。有时候业务方会说系统要快，但“快”这个词太主观了。非功能性需求必须准确、可度量、可完成、可测试。大多数非功能性需求是一些技术的天然属性，并且会直接影响软件架构。

Clearly Define Harder Than Maybe Assume

• 系统设计
  每一个软件系统都有一套设计，但不是每一个软件系统都有一套架构。
  架构一定是设计，而设计不一定是架构。架构是重要的设计，架构给出被强制执行的限制，并在限制基础上解决问题。 架构是框架、纲领、原则和技术预言。

Define From Blank Harder Than Re-use From Other

• 技术选型
  技术选型包括但不限于复杂度、三方依赖、技术策略、部署方案、升级政策、端用户环境。技术选型的本质是管理风险，既要知道选型带来的高复杂度和不确定性，也要知道选型带来的好处。

Confidently Evaluate Harder Than Easily Pick

• 设计评估
  当你在设计软件时，你需要问自己这套架构可行么？我会有三个思考方向，满足非功能性需求，提供实现功能需求的框架、以及足够的空间去解决潜在的业务问题。 实际上，我们在持续不断的验证架构可行，前期UML设计图的评审、中期反复的测试、后期线上的监控。越早验证系统，就能降低更多的风险。

Prove Harder Than Assume

• 架构协作
  软件系统几乎不会在孤立中存在，从需要理解并认同架构的实际开发者，到对系统的安全性、维护性等感兴趣的人，架构一定需要被人理解。
  为了软件产品的成功，架构师有必要和系统相关的人密切合作，以便保证架构能够和环境完美的集成。

Involved Work Harder Than Delivered Document

架构的交付

同“定义”一样，取决于“架构师的投入程度”，交付也会在一个区间内波动。

• 架构的所有权
  为了让架构成功的落地，需要有个人坚持架构原则并不断向开发团队确认，在整个开发周期中负起责任。

Take Ownership Better Than Hand Over

• 领导力
  在开发过程中，团队是否处于正确的方向，是否需要技术引领，是否做了合适的技术决策，作为架构师，有必要保证每件事都被认真对待了。

Take Leadership Better Than Receive Direction

• 教练和指导
  领导是在团队层面保证开发在正确的方向上稳步前进，个体的支持和帮助，在不少团队中被忽视了，这会增强个人的能力和事业。值得注意的是，在架构和设计上提供指导，和解决变成问题是有很大差距的。

Coaching and Mentoring Better Than Being coached or mentored

• 质量保证
  项目完全有可能因为一个bug而导致失败。
  质量保证，不仅仅是代码审查，也可以是代码规范、设计原则、源码分析、AT测试、覆盖率检查等等CI工具，不同的人会看重不同的事情，我的是架构的重要性，复杂度和高度可视化。

Do Something Better Than Do Nothing

• 设计、开发、测试
  回到架构角色开发者的本质，设计架构、开发实现、测试交付。和开发团队密切接触，不是要求你天天写代码，是要求你持续的投入项目，帮助构造和交付。不得不说，写代码也是有必要的，它会让你感受到开发者在架构设计中的痛点，从而帮助你从开发者的视角更好地理解架构。
  当然，代码级别的介入在有些场合并不实际，因为在“那样大”的项目中，架构师需要关心的事太多了。

Being Involved Better Than Watching Aside

尾声

无论你是否感受到了那条虚无的线，文章中提到的点在不同的团队中确有不同，“不同”取决于架构师的“投入程度”和“对待角色的严肃程度”。 大多数开发者不会在某一天醒来，然后突然宣布自己是一个架构师。在职业中开始架构是一个渐变的过程，我敢打赌，有一些开发者，和他们的职业头衔不相符的，已经开始承担部分架构的角色了。

参与软件系统的开发，和自主设计并负责软件系统，是非常不一样的。是否跨过开发和架构中间的线，完全取决于你自己，对自己作出准确的角色定义是跨越的开始。