架构师是什么？
架构师这词其实很有意思，很多人的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这种等。也不用太多，覆盖典型的4~5个领域就可以解决很大的问题了。这应该会更有效果，但课程创建上会比较吃力些，真想做的人要有思想准备。我个人曾经尝试和南京的TalenCamp按照第二条路来设计课程，但由于各种原因暂时进展不太大。
作者介绍：李智勇，V众投发起人，《完美软件开发：方法与逻辑》作者。目前正在免费发布《程序员生存定律》，微博：李智勇SZ，微信：vfacebook。
《畅言》第九期：【[畅言]你真的了解软件开发的本质吗？】我们总是喜欢用自己的经历来定义软件是什么以及判断标准，但如果这种经历来自完全不同的两个领域，并且互相矛盾，那么就有可能让大家吵来吵去……是的，各位在忙于解决具体问题时，谁还会想到谈谈软件开发的本质？
《畅言》第十期：【[畅言]程序员可以只关心技术么？】不少程序员爱维护喜欢的技术，虽然他们说的有道理，但程序员价值的实现并不取决于技术。模式不一样，程序员价值也不一样，而这也暗含了程序员生涯的两个进阶模式，读完此文，相信你会重新思考个人生涯发展方向。
《畅言》第十一期：【畅言]软件工程的根本问题】软件工程基于思维承载之物的特质，必然会有清晰的适用边界。但实际上恰恰与此相反，每当一种工程方法出世的时候，它的作用总是潜在的有扩大的趋势，似乎一旦锤子在手之后，所有身边的东西就都变成了应锤一锤的钉子。
《畅言》是CSDN新栏目，供大家各抒己见。只要你看完CSDN文章或评论后有话说，都可以通过电子邮件（zhangyong@csdn.net）投稿，从而获得上CSDN首页表达自己观点、想法的机会。《畅言》不怕观点“雷人”，只要你逻辑表达清楚、数据引用可靠，你敢投稿，我们就敢首页！欢迎大家畅所欲言。
京公网安备 11010802040832号 | 京ICP备19059560号-6 