前言
在软件设计中，人们对很多概念存在误解，或者模糊不清，其中一个最为普遍的误解就是：将架构和框架混为一谈。还有对类库和框架的区别是什么很疑惑。本文就这些概念性的问题做一个总结性区分以方便大家理解其中的内涵，也算是架构设计的一篇入门级文章。
诸概念简析
类库：类库是类的集合，这些类之间可能是相互独立的。应用开发者希望使用任何一个类时可以直接调用它(实例化后调用其中的方法)，
而不必自己再创建一个类。
框架：通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，
也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
归根到底是可复用的“半成品”软件，有的大型的框架中也会用到架构设计。
构架：进行时态的架构（建立架构中的动作）
架构：是一系列相关的抽象模式（模式是主体行为的一般方式，是理论和实践之间的中介环节，），是软件的体系结构，是一个系统的草图。
用于指导大型软件系统各个方面的设计（有时候也用于框架的设计）。
架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，
解决这个问题的实践活动。包括拆分的原则以及理由，沟通合并的原则以及理由，
以及拆分出来的各个部分和合并所对应的角色及所需要的核心能力等。
用一句概括下：
一个 架构师使用类库构架了一个框架，约束框架使用者只能使用规定的结构来进行二次开发。
框架VS类库
类库是类的集合，这些类之间可能是相互独立的。应用开发者希望使用任何一个类时可以直接调用它，而不必再写一个。
与类库相比，框架和类库有着相似的形式，即框架也往往是类的集合；但不同之处在于，框架中的各个类并不是孤立的，
而框架中的业务逻辑代码是将不同的类“连”在一起，在它们之间建立协作关系。那么框架的设计人员就要运用其架构和领域知识，
来定义框架内的组件该如何协作。
框架通过封装处理流程的控制逻辑，使它对开发者透明，来简化开发工作。这种封装也是框架和类库（class library）的区别之一。
类库由许多现成的、供开发者用于构建应用的组件组成，但是，开发者必须理解不同组件之间的关系，
并编写处理流程代码把众多组件组织起来。
框架则不同，它通过预先把众多组件组织在一起的方式，封装了处理流程的控制逻辑；因此，
开发者就不用再编写控制逻辑来组织组件之间的交互。
架构VS框架
框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。
典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用系统直接调用，
而框架中的扩展点是供应用开发人员定制的“可变化点”。
软件架构不是软件，而是关于软件如何设计的重要决策。
软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。
经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，架构决策往往会体现在框架之中。
或许，人们常把架构和框架混为一谈的原因就在于此吧！
我们不能指着某些代码，说这就是软件架构，因为软件架构是比具体代码高一个抽象层次的概念。
架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。
架构师的职责
架构师：是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。架构师不是一个人战斗，他需要建立高效的体系，带领团队去攻城略地，在规定的时间内完成项目。
我们这里说的是互联网软件架构师而不是架构师这个大类，不是放眼各个行业的架构师。
首先要搞清楚架构师主要做些什么
更加详细的架构师职责
image
1 确认需求
架构师要懂得用户需求，理解用户真正想要什么，这使得架构师必须要和分析人员不断沟通，
反复确认需求规格说明书，以此来保证他精准清楚用户需求。
架构师会与很多人沟通，例如开发人员，例如我们项目经理，有时甚至是用户本身。
架构设计的目的很明确，目的是什么呢？挖掘用户需求。
2 系统分解
在架构师认可需求规格说明书后，架构师已明确用户需求是是什么，这时候便看架构师的分解能力了。
系统分解一般从「纵向分解」和「横向分解」
「一般分为纵向分解和横向分解，
纵向分解是将整个系统分层，从而将整体系统分解成下一级的子系统与组件。
横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系。」
3 技术选型
在系统分解后，架构师会最终形成软件整体架构，接下来，架构师的职责是技术选型。
「前端到底用瘦客户端还是富客户端呢？数据库是用MySQL还是MSSQL又或是Oracle呢？」
在了解用户需求后，分解完系统后，技术选型是非常重要的环节，提出各个方向，再进行评估。
不过，很多人都以为架构师是有决定权的，其实不是，架构师没有拍版的权力，决定由项目经理来做。 」
架构师在技术选型阶段会提供参考信息给项目经理，项目经理再从预算、进度、人力、资源等各方面情况来权衡，最终确认。
4 制定技术规格说明
如前文调查显示，架构师在项目开发过程中是「灵魂人物」，并且要具备协调组织能力和懂得人员分工。
在制定技术规格说明阶段，架构师要协调起所有的开发人员，架构师通常会用技术规格说明书与开发人员保持沟通，
让开发人员能从各个视角去观测、理解他们负责的模块或者子系统，确保开发人员能够按照架构意图实现各项功能。
在了解架构师的职责后，再来看看架构师该具备什么能力才能成为一家公司中的「灵魂人物」。我们先来看一下调查数据——
image
37%的受访人认为架构师的设计能力最重要，
技术实力重要度排在第二占了24%，
沟通能力则排在第三，占比14%，
管理能力在大多数架构师眼中并不是最重要的，仅占了7%。
1 设计能力－擅长整合分析
架构是过程，并非结果。
架构是架构师洞察内在结构、原则、规律与逻辑的过程，架构师要做到清晰理解系统，以及简洁描述，这是分析整合的能力。
一个架构师必须具备极强的分析能力，要做到根据产品宗旨和目标，分析清楚产品定位以及产品业务，
再整合利用现有的技术领域，找出最佳方案，实现产品概念。
2 技术实力－实现产品规划
架构师首先要将代码写的清晰易懂，要能够实现功能，做到没有Bug，这要求架构师必须具备至少熟练掌握一门语言。
这是最重要的，每一名出色的架构师，必定是一位优秀程序员。架构师并不是纯粹的管理岗位，
对那些爱写各式文档、画流程图、脱离代码、只说不做、高高在上的架构师，程序员们通常会称他们为——PPT 架构师。
不懂编程的架构师的职业生涯必定是短暂的，无论如何都不可本末倒置，要想实现自己的职业规划，
不能荒废自己本身的技能，技术是架构师赖以生存的最基本能力。
所以，不推荐不热爱编程的人去做架构师，对于团队工作和个人发展来说，都会带来糟糕的后果。
3 沟通能力－能够横向沟通
架构师必须参与项目开发全过程，包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段，在这一系列过程中，架构师会与各部门沟通交流。
一个产品会有多部门合作，架构师在其中的沟通极为重要，直接影响产品进度与质量。架构师不仅要与开发人员沟通，
也要和项目经理、分析人员甚至用户沟通，来实现产品的各种可能性。
所以，对于架构师来讲，不仅有技术方面的要求，还有能够横向沟通的要求
一位开发者如何才能成为一位架构师？他/她需要掌握哪些领域之外的能力？
经验。大部分优秀软件架构师同时也是出色的软件开发者，他们都是经过时间逐渐发展成为架构师的。你需要有退后一步看代码的能力，从而理解特定软件系统背后的设计决策。退后一步才能看到“大局”，这是架构师必须掌握的核心技能。
------致敬想成为架构师的你
网友评论