什么是架构师？建筑师这个词其实很有意思。很多人的Title是这样的，但其实我们对架构师是做什么的并没有一个统一的认识。大的时候，比尔盖茨好像自称架构师，小的时候，凡是设计什么小软件的，也都自称为架构师。所以如果把这个词广义化，不局限于特定的场景，光是搞清楚什么是架构师，估计就需要流很多口水了。让我们用一个取巧的方法来看看架构师在特定场景下应该做什么，而不是泛化这个词。如果清楚这个角色在特定场景中应该做什么，那么它对其他场景可能会有用。下面提供了一个很好的参考。我们只考虑从头开发一个产品的场景，并没有考虑这个产品可能是一个家庭，可能需要配合公司里的很多东西。这样，问题就可以简化为：当我们要开发一个新产品时，架构师应该做什么？为了更具体一点，我们进一步假设公司想要构建一个协作办公工具，例如Trello和Worktile。在产品的前期，除了UI之类的东西，可以明确的一些关键需求大致有：简单、快速、追求最好的用户体验。时时进入信息流的机制）移动端支持公司的判断：如果产品能在一年内推出，时机更好。其他的需求肯定是有的，只是基于这么简单的提醒，暂时还不清楚。脑子里可能会立刻冒出无数的事情，比如：快保证？拖入看板的实现？确保SaaS的可扩展性？数据库表的设计？数据库类型的选择？如何支持移动端？人员现状？支持迭代开发？……但显然不是所有的事情都必须在架构设计阶段就完成，否则无异于糊里糊涂。这时，架构师的一个关键职责就是能够区分哪些事情需要提前完成，哪些事情需要在迭代过程中解决。一般来说，更换成本越大，涉及的人越多，架构师提前做的事情就越多，否则很容易做无用功，对开发工作造成致命的伤害。具体来说，这种东西由三个核心部分组成：选择TechStack的概要设计，建立分工基础协作方式我来解释一下这三个方面的具体含义。选择TechStack是指选择包括编程语言、基础框架等一系列的东西，比如选择了Trello之后，大致是这样的：这个东西几乎是不可替代的，因为替代成本已经达到了那个水平一个正常的团队不可能有那么点包袱。因此，TechStack与待开发产品的契合程度，是体现架构师价值的地方。选择了TechStack却发现未能实现产品目标是架构设计中最糟糕的结果，而且因为输不起，所以可以在这个环节更加谨慎。这个TechStack的选择受限于上面提到的关键需求，比如速度快，支持移动端等，也就是说，从需求模型到技术模型的映射。懂一些技术的应该能一眼看出上图是MEAN（MongoDB、Express、AngularJS...、NodeJS）架构。这种架构满足上面的关键需求是没有问题的，但是如果其中一个关键需求是灵活的插件结构来满足不同用户的定制需求，那么上面的结构可能就有点麻烦了。无论如何，TechStack架构师是第一个需要做的事情，没有它他们什么也做不了。二是相对传统的部分。无论从哪里开始迭代，总是需要划分前端和后端的职责，设计相互交互的接口。需要区分哪些是纯工具类模块（比如日志），哪些是基础设施类（比如用户管理和权限），哪些是可以完全迭代的（比如某个特定功能）。这些东西之间是有内在的时序关系的，不是简单的一句话：我们迭代吧，我们测试驱动开发，没关系，那会造成很多混乱，所以这就是架构师发挥作用的地方。传统上，这称为概要设计。虽然这个词现在用的不多，但其实是个好词。当然，架构师不一定要一个人处理所有这些事情，而是必须肩负起协调大家处理这些事情的责任。这个地方取决于对业务知识要求不同的产品类型：一般来说，越是个人化的产品，对业务知识的要求越低；越是面向企业的产品，对业务知识的要求就越高。简单来说，做天气应用的时候直接做可能就够了，但是做金融应用的时候需要了解一些金融知识。最后一种是分工后的协同方式，包括分支策略、持续集成策略等。显然，在下面两种分支策略下，团队的协同方式是不同的。这又是一个整体性的工作，在工作之前需要预先确定这一点应该是毋庸置疑的，但这件事不是架构师能搞定的。不同的人认知可能不一样，有的人认为应该是项目经理的角色来处理这件事情。我个人坚持理想情况下架构师应该处理这个问题，因为分支策略等更受技术限制。这是我理解的架构师需要做的三类工作：选择一个TechStack，概要设计建立分工基础，建立协作方式。在开发产品的时候，如果这三件事没有做好，迭代就不好迭代。从抽象的角度来看，它是这样的：假设在现有人员的基础上，提前解决某个问题的成本为X，迭代后，遇到问题时处理的成本为Y，那么毫无疑问，Y>X的问题应该尽量提前处理，不能以迭代为借口而置之不理。以上三个问题基本上是Y>X。如何成为一名建筑师？我首先要说的是，程序员不必是架构师。优秀的程序员同样有价值，但关键还是看技术领域。作为程序员我能只关心技术吗？这件事我特地提到过，这里就不展开了。如果你真的想成为一名架构师，总有两种方法。这两类方法并不局限于架构师的学习，而是普遍适用于任何学习。一是从概念规则到实践，二是从实践中总结概念和规则。数学更接近前者，历史更接近后者。当我们试图抽象出什么是架构设计，架构设计的原则是什么，然后让大家明白现实中是如何做架构设计的时候，无疑采用的是前一种方法，即数学方法。这种方法在现实中比较常见，但在逻辑上是有问题的：正是因为对架构设计缺乏了解，人们才去尝试学习架构设计，也就是说，想这样学习的人天生就有能力了解架构设计的概念和原则。遇到困难。出于这样的考虑，最好的办法是先了解一些最基本的概念，比如上面提到的那些，然后了解一些最基本的原理，比如：正交性，信息隐藏等。之后，它不会在抽象概念的层面上旋转。并且了解现有的多个典型产品的架构，比如上面提到的Trello和WordPress。这时候最好对产品进行分类，在特定的类别下抽象出一些典型的架构模式。比如：软硬件一体化产品的架构，CMS的架构等。这样，一个人如果能主要学习其中的一个，顺便了解其余的，就可以很快掌握架构设计的知识，至少前面提到的架构设计中的前两类知识：TechStack选择和概要设计。在开源时代，这已经成为一个人坐在家里就可以做的事情。一点点呼吁***一点点呼吁。现在各种架构设计的课程还是很多的，但是基本上都是基于第一种思路，比如：讲架构设计的时候，会尽量把架构设计分解成逻辑架构、运行架构等。我身边人的效果，一般都不太理想。有实力的培训机构可以尝试总结架构模型，以大纲引领几个典型领域的架构分析。比如CMS架构参考WordPress，基础JavaScript库参考Backbone等，不需要太多，典型的覆盖4~5个领域就能解决一个大问题。这样应该会比较有效，但是创建课程会比较困难，真正要做的人要有心理准备。我个人在南京的TalenCamp尝试过按照第二种路线设计课程，但由于种种原因，进展不是太大。
