网站架构师的工作内容( 架构师是什么？架构师这词都要干些什么样？)

　　网站架构师的工作内容(

架构师是什么？架构师这词都要干些什么样？)

　　什么是建筑师？

　　建筑师这个词其实很有趣。很多人的Title是这样的，但其实我们对于建筑师是做什么的并没有一个统一的认识。再大一点的时候，比尔·盖茨似乎自称是建筑师，而年轻的时候，他在设计一个小软件时说自己是建筑师。所以，如果这个词泛泛而谈，不局限于具体的场景，估计要说清楚什么是架构师，还需要很多口水。让我们使用一个棘手的方法来看看架构师在特定场景中应该做什么，而不是一概而论。如果明确了这个角色在特定场景中应该做什么，那么它可以用于其他场景。下面提供了一个很好的参考。

　　我们只考虑从零开始开发一个产品的场景，没有考虑这个产品可能是一个家庭，可能需要与公司很多东西合作的繁琐事情。这将问题简化为：当我们想要开发新产品时，架构师会做什么？为了让事情更具体，让我们进一步假设该公司想要制作像 Trello、Worktile 这样的协作办公工具。

　　产品前期，除了UI之类的东西，可以明确的一些关键需求大概如下：

　　其他的需求肯定是有的，但我暂时说不出来。

　　基于这样简单的提示，在做程序很久的人的脑海中可能会立刻蹦出无数的东西，比如：

　　但显然不是所有的事情都必须在建筑设计阶段完成，否则就等于上当了。这时，架构师的一个关键职责就是能够区分哪些需要提前完成，哪些需要在迭代过程中完成。解决。

　　一般来说，更换成本越大，涉及的人越多，越是需要架构师提前做好的事情，否则很容易做无用的工作，对开发工作造成致命的伤害。具体来说，这种东西由三个核心部分组成：

　　下面解释这三个方面的具体含义。

　　选择Tech Stack是指选择包括编程语言、基础框架等一系列的东西。比如选择Trello之后是这样的：

　　这东西几乎是不可重置的，因为重置成本已经到了普通团队无法承受的地步。因此，Tech Stack 与待开发产品的契合程度是体现架构师价值的地方。我选择了Tech Stack，但发现无法实现产品目标是架构设计方面最糟糕的结果，因为我输不起，所以在这个环节我可以更加谨慎。这个Tech Stack的选择受限于上述的关键需求，比如快速、移动支持等。也就是常说的需求模型到技术模型的映射。

　　懂一些技术的人应该一眼就能看出上图就是MEAN（MongoDB、Express、AngularJS...、NodeJS）架构。这个架构满足上面的关键需求是没有问题的，但是如果其中一个关键需求叫做灵活的插件式结构来满足不同用户的定制化需求，上面的架构可能就有点麻烦了。

　　无论如何，Tech Stack 架构师是他需要做的第一件事，没有它他什么都做不了。

　　第二部分是比较传统的部分。无论从哪里开始迭代，总是需要划分前端和后端的职责，设计相互交互的接口，区分哪些是纯工具模块（如日志），哪些是纯工具模块（如日志）基础设施（如用户管理和权限），可以彻底迭代（如特定功能）。这些东西之间有内在的时序关系，不是一句简单的话：让我们迭代，让我们测试驱动开发，没关系，这会导致很多混乱，所以这就是架构师发挥作用的地方。传统上，这被称为大纲设计，虽然这个词*敏*感*词*融应用的时候还是需要了解一些金融知识的。面向企业的产品越多，对业务知识的要求就越高。简单来说，做天气应用的时候直接做可能就够了，但是做金融应用的时候还是需要了解一些金融知识的。面向企业的产品越多，对业务知识的要求就越高。简单来说，做天气应用的时候直接做可能就够了，但是做金融应用的时候还是需要了解一些金融知识的。

　　第一种是分工后的协同方式，包括分支策略、持续集成策略等。

　　显然，在以下两种分支策略下，团队以不同的方式进行协作。

　　这是另一项整体工作。毫无疑问，它需要在工作之前预先确定，但不是建筑师做的。不同的人可能有不同的看法。有人认为应该是项目经理。类角色来做到这一点。就个人而言，我坚持架构师应该理想地处理这个问题，因为分支策略等更多地受到技术的限制。

　　这就是我对架构师需要做的三类工作的理解：选择Tech Stack，大纲设计建立分工基础，建立协作方式。

　　在开发一个产品的时候，如果这三件事没有做好，就不容易进行迭代。从抽象的角度来看是这样的：假设在现有人员的基础上，提前解决某个问题的成本为X，迭代后处理该问题的成本为Y，那么有毫无疑问，Y>X的问题应该尽量提前处理，不能以迭代为借口忽视。以上三个问题基本都是Y>X。

　　如何成为一名建筑师？

　　我想说的第一件事是程序员不必是架构师。优秀的程序员同样有价值，但关键还是要看技术领域。作为程序员，我能只关心技术吗？这个我特意说了，这里就不展开了。

　　事实上，成为建筑师总是有两种方法。这两种方法不仅限于建筑师的学习，而且对任何学习都是通用的。

　　一是从概念规则到实践，二是从实践中总结概念和规则。数学更接近前者，历史更接近后者。当我们尝试先抽象什么是建筑设计，什么是建筑设计原则，然后让大家知道在现实中如何做建筑设计时，我们无疑采用了前一种方法，即数学方法。这种方法在现实中比较常见，但逻辑上存在问题：正是因为对建筑设计缺乏了解才试图学习建筑设计，也就是说，想学的人天生就有对概念的理解和建筑设计的原则。遇到困难。

　　对于这样的考虑，最好的方法是先了解一些最基本的概念，比如上面提到的那些，然后再了解一些最基本的原理，比如：正交性、信息隐藏等。不要在抽象概念的层面上旋转。并且了解很多现有的典型产品的架构，比如上面提到的Trello、WordPress等。这时候对产品进行分类，将一些典型的架构模式抽象到特定的类别下。比如：软硬件集成产品的架构，cms的架构等。这样一个人如果能主要学习其中一个，其余的学习一下，就能很快掌握这方面的知识。架构设计，至少上面提到的架构设计中的前两类知识：Tech Stack设计的选择和总结。在开源时代，这已经成为一个人坐在家里就能做的事情。

　　吸引力不大

　　*** 提出一点上诉。各种架构设计的课程还有很多，但基本都是基于第一个思路。比如我们讲架构设计的时候，会尽量把架构设计分解成逻辑架构、操作架构等，从周围人的效果来看，一般都不太理想。有实力的培训机构可以尝试总结架构模式，大体上引领几个典型领域的架构分析，例如：cms指架构的WordPress，基础的JavaScript库指Backbone等。 t需要太多，覆盖一个典型的4-5个区域就可以解决一个大问题。这应该更有效，但是课程创建会比较困难，而真正想做的人，应该做好心理准备。我个人尝试过按照第二种方式在南京跟TalenCamp一起设计课程，但是由于种种原因，暂时进展不大。

　　这篇文章的链接：