架构概念简析及初识架构师

类库：类库是类的集合，这些类之间可能是相互独立的。应用开发者希望使用任何一个类时可以直接调用它(实例化后调用其中的方法)，
     而不必自己再创建一个类。

框架：通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，
     也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。
     归根到底是可复用的“半成品”软件，有的大型的框架中也会用到架构设计。

构架：进行时态的架构（建立架构中的动作）

架构：是一系列相关的抽象模式（模式是主体行为的一般方式，是理论和实践之间的中介环节，），是软件的体系结构，是一个系统的草图。
     用于指导大型软件系统各个方面的设计（有时候也用于框架的设计）。
     架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，
     解决这个问题的实践活动。包括拆分的原则以及理由，沟通合并的原则以及理由，
     以及拆分出来的各个部分和合并所对应的角色及所需要的核心能力等。

类库是类的集合，这些类之间可能是相互独立的。应用开发者希望使用任何一个类时可以直接调用它，而不必再写一个。

与类库相比，框架和类库有着相似的形式，即框架也往往是类的集合；但不同之处在于，框架中的各个类并不是孤立的，
而框架中的业务逻辑代码是将不同的类“连”在一起，在它们之间建立协作关系。那么框架的设计人员就要运用其架构和领域知识，
来定义框架内的组件该如何协作。

框架通过封装处理流程的控制逻辑，使它对开发者透明，来简化开发工作。这种封装也是框架和类库（class library）的区别之一。

类库由许多现成的、供开发者用于构建应用的组件组成，但是，开发者必须理解不同组件之间的关系，
并编写处理流程代码把众多组件组织起来。

框架则不同，它通过预先把众多组件组织在一起的方式，封装了处理流程的控制逻辑；因此，
开发者就不用再编写控制逻辑来组织组件之间的交互。

  框架是一种特殊的软件，它并不能提供完整无缺的解决方案，而是为你构建解决方案提供良好的基础。框架是半成品。
  典型地，框架是系统或子系统的半成品；框架中的服务可以被最终应用系统直接调用，
  而框架中的扩展点是供应用开发人员定制的“可变化点”。

  软件架构不是软件，而是关于软件如何设计的重要决策。
  软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。
  经过完整的开发过程之后，这些架构决策将体现在最终开发出的软件系统中；当然，架构决策往往会体现在框架之中。
  或许，人们常把架构和框架混为一谈的原因就在于此吧！

  我们不能指着某些代码，说这就是软件架构，因为软件架构是比具体代码高一个抽象层次的概念。
  架构势必被代码所体现和遵循，但任何一段具体的代码都代表不了架构。

架构师要懂得用户需求，理解用户真正想要什么，这使得架构师必须要和分析人员不断沟通，
反复确认需求规格说明书，以此来保证他精准清楚用户需求。

架构师会与很多人沟通，例如开发人员，例如我们项目经理，有时甚至是用户本身。
架构设计的目的很明确，目的是什么呢？挖掘用户需求。

在架构师认可需求规格说明书后，架构师已明确用户需求是是什么，这时候便看架构师的分解能力了。

系统分解一般从「纵向分解」和「横向分解」

「一般分为纵向分解和横向分解，
  纵向分解是将整个系统分层，从而将整体系统分解成下一级的子系统与组件。
  横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系。」

在系统分解后，架构师会最终形成软件整体架构，接下来，架构师的职责是技术选型。

「前端到底用瘦客户端还是富客户端呢？数据库是用MySQL还是MSSQL又或是Oracle呢？」      
  在了解用户需求后，分解完系统后，技术选型是非常重要的环节，提出各个方向，再进行评估。
  不过，很多人都以为架构师是有决定权的，其实不是，架构师没有拍版的权力，决定由项目经理来做。 」

 架构师在技术选型阶段会提供参考信息给项目经理，项目经理再从预算、进度、人力、资源等各方面情况来权衡，最终确认。

如前文调查显示，架构师在项目开发过程中是「灵魂人物」，并且要具备协调组织能力和懂得人员分工。

在制定技术规格说明阶段，架构师要协调起所有的开发人员，架构师通常会用技术规格说明书与开发人员保持沟通，
让开发人员能从各个视角去观测、理解他们负责的模块或者子系统，确保开发人员能够按照架构意图实现各项功能。

37%的受访人认为架构师的设计能力最重要，
技术实力重要度排在第二占了24%，
沟通能力则排在第三，占比14%，
管理能力在大多数架构师眼中并不是最重要的，仅占了7%。

架构是过程，并非结果。

架构是架构师洞察内在结构、原则、规律与逻辑的过程，架构师要做到清晰理解系统，以及简洁描述，这是分析整合的能力。

一个架构师必须具备极强的分析能力，要做到根据产品宗旨和目标，分析清楚产品定位以及产品业务，
再整合利用现有的技术领域，找出最佳方案，实现产品概念。

架构师首先要将代码写的清晰易懂，要能够实现功能，做到没有Bug，这要求架构师必须具备至少熟练掌握一门语言。

这是最重要的，每一名出色的架构师，必定是一位优秀程序员。架构师并不是纯粹的管理岗位，
对那些爱写各式文档、画流程图、脱离代码、只说不做、高高在上的架构师，程序员们通常会称他们为——PPT 架构师。

不懂编程的架构师的职业生涯必定是短暂的，无论如何都不可本末倒置，要想实现自己的职业规划，
不能荒废自己本身的技能，技术是架构师赖以生存的最基本能力。

所以，不推荐不热爱编程的人去做架构师，对于团队工作和个人发展来说，都会带来糟糕的后果。

架构师必须参与项目开发全过程，包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段，在这一系列过程中，架构师会与各部门沟通交流。

一个产品会有多部门合作，架构师在其中的沟通极为重要，直接影响产品进度与质量。架构师不仅要与开发人员沟通，
也要和项目经理、分析人员甚至用户沟通，来实现产品的各种可能性。

所以，对于架构师来讲，不仅有技术方面的要求，还有能够横向沟通的要求

                                                                           ------致敬想成为架构师的你