从程序员到架构师的方法与逻辑

架构师这个词常常见到，不少人都冠着这个头衔，实际上不少人对架构师到底是干什么的都没有统一的认识。V众投发起人李智勇则利用特定场景进行分析，诠释了架构师这个概念，并给出如何成为架构师方法。

架构师是什么？

架构师这词其实颇有意思，不少人的Title是这个，但其实咱们对架构师都干什么并无太统一的认识。往大了说，比尔盖茨当年好像也称本身为架构师，往小了说随便一个小的软件上作设计的也说本身是架构师。因此若是把这个词泛化而不局限于特定的场景，估计单是说清楚什么是架构师就要花费很多口水。下面咱们用一个取巧的办法，在一个具体的场景下来看看，架构师都该干什么，而不把这个词泛化，若是在特定场景下这个角色应该干什么清楚了，那它就能够为其它场景下提供不错的参考。

咱们只考虑从头开发一款产品的场景，不考虑这款产品多是个家族，可能须要在公司里与许多东西配合这样繁琐的事情。这样问题就简化成：当咱们要开发一款新产品的时候，架构师都要干些什么？为让事情更具体，咱们进一步假设公司想作一个Trello，Worktile这样的协同办公工具。

在产品初期除了UI这类东西，还能明确的一些关键需求大概是这样：

• 简单、迅速，追求极致的用户体验，这时也许能想到看板这样的功能
• 打入社交元素（任务分配与沟通时打入信息流的机制）
• 移动端支持
• 公司判断：若是产品能在1年内上线，时机比较好

其余的需求呢就是感受上确定有，但暂时说不清楚

基于这样的简单提示，长作程序的可能脑子里会马上冒出来无数东西，好比：

• 快的确保?
• 看板里拖动的实现？
• SaaS时伸缩性的确保？
• 数据库中表的设计？
• 数据库类型的选择？
• 移动端的支持方式？
• 人员的现状？
• 迭代式开发的支持？
• ... ...

但显然不是每一个事情都要在架构设计阶段搞定，不然等因而被弄蒙了，这时候架构师的一个关键职责就是要能区分出哪些东西预先须要搞定，而哪些东西则要在迭代过程当中解决。

通常来说重置成本越大，牵涉的人越多的事情越应该由架构师预先搞定，不然就容易作无用功，对开发工做产生致命伤害。具体来说这类事情由三个核心部分组成：

• 选定Tech Stack
• 概要设计，确立分工的基础
• 协同方式

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

选定Tech Stack是指要选定包括编程语言，基本框架等一系列东西，好比Trello选完以后大体是下面这个样子：

图片来自网络

这事情几乎是不可重置的，由于重置成本已经到了正常团队不可能负担的地步。因此Tech Stack与待开发产品的吻合程度是很是体现架构师价值的地方。选了Tech Stack但发现没法达成产品目标是架构设计上最差的结果，也正由于输不起，在这个环节上能够慎重些。这种Tech Stack的选择受限于上述所说的关键需求，好比快，支持移动端等。也就是常说的从需求的模型想技术模型的映射。在此我向你们推荐一个架构学习交流群。交流学习群号：948368769里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

了解些技术的应该一眼能够看出来上面这张图是MEAN（MongoDB，Express，AngularJS。。。，NodeJS）架构，这架构知足上面关键需求是没问题的，但若是关键需求里有一条叫以灵活的插件结构来知足不一样用户的定制化需求，上面这架构可能就有点麻烦了。

无论怎么样Tech Stack架构师第一个须要搞定的事情，没这个什么活也干不了。

再其次则是相对比较传统一点的部分，无论从哪里开始迭代，老是要切分前端后端的职责，设计彼此交互的接口，要区分出来哪些是纯工具型的模块（好比日志），哪些是基础设施型的（好比用户管理与权限），哪些是能够完全进行迭代的（好比具体的某个功能）。这些东西之间是有一种内在的时序关联的，不是简单一句：咱们迭代吧，咱们测试驱动开发吧，就能够的，那会致使很大的混乱，因此这里也是架构师要扮演角色的地方。传统上管这个叫概要设计，虽然这词如今不怎么用了，但这词其实还不错的。固然架构师不必定要一我的搞定全部这些事情，而是要肩负起协调你们搞定这些事情的职责。这个地方依赖于产品的类型对业务知识的要求程度不一样：通常来说越是面向我的的产品，在业务知识上要求越低；越是面向企业的产品业务知识的要求越高。简单讲作天气应用的时候可能直接作就好了，但作财务应用时了解财务的某些知识就挺必须的。

最后一项则是分工后的一种协做的方法，这里面包含着分支策略，持续集成策略等。

显然的，下面两种分支策略下，团队的协做方式不同.。

图片来自网络

这是又一个全局性的工做，干活前须要预先定下来应该也是没疑问的，可是不是架构师搞定这事上，不一样人的认知可能会不同，有的人会认为应该是项目经理类的角色来搞定这事情。我我的则坚持认为理想情形下应该架构师搞定这事，由于分支策略等受技术的约束更大。

这就是我理解中架构师的要干的三类活：选择Tech Stack，概要设计来确立分工的基础，确立协同的方式。

在开发产品时，这三样事情不搞定，迭代都很差迭代。抽象点来看是这样：假设说在现有人员的基础上，预先搞定某问题须要耗费的成本为X，而迭代后，事到临头再处理，其耗费的成本为Y，那么无疑的Y>X的问题都应该是尽量预先处理的问题，而不能以迭代为借口冠冕堂皇的进行忽视。而上述三方面问题，基本上是Y>X这类。

如何成为架构师？

首先想说的是程序员不必定要成为架构师的，优秀的程序员同样颇有价值，但关键要看技术领域，我在程序员能够只关心技术么？ 专门说过这事，这里再也不展开。

真要想成为架构师事实上老是有两类方法，这两类方法倒不局限于架构师的学习，而是普适于任何学习。

一种是从概念规则到实践，一种则是从实践总结出概念和规则。数学更近似前者，而历史更近似后者。当咱们试图先抽象出什么是架构设计，架构设计又有那些原则，以后再让你们了解现实中的架构设计如何作时，无疑的采起的也是前者的方式，也就是数学的方式。这种方式在现实中比较常见，但在逻辑上是有问题的：正是由于对架构设计的不理解，才尝试学习架构设计，即如此想学习的人天生在了解架构设计的概念与原则会遭遇困难。在此我向你们推荐一个架构学习交流群。交流学习群号：948368769里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

出于这样一种考虑，最好的办法实际上是先了解一些最基本概念，好比前面说的那些，再了解一些最基本的原则，好比：正交，信息隐藏等。以后就不在抽象概念层面打转了。而了解多个现有典型产品的架构，好比上面说的Trello，WordPress等。这时候最好对产品归类，在特定类别下抽象出来一些典型的架构模式。好比：软硬一体产品的架构，CMS的架构等。这样一来，若是一我的能够主要学习其中之一，顺道了解其他，那就能够比较迅速的掌握架构设计的知识，至少是上面说的架构设计中的前两类知识：Tech Stack的选择与概要设计。在开源的时代里，这已经成为一我的坐在家里就能够完成的事情了。

一点呼吁

最后作一点呼吁。如今各类架构设计的课程仍是比较多的，但基本上都是按照第一条思路来的，好比：讲架构设计时会去尝试把架构设计分解为逻辑架构，运行架构等。从身边人的效果来看，广泛不太理想。有实力的培训机构能够尝试总结架构的模式，以一个总纲带领几个典型领域的架构分析，好比：CMS就参照WordPress来说架构，基础JavaScript库就参照Backbone这种等。也不用太多，覆盖典型的4~5个领域就能够解决很大的问题了。这应该会更有效果，但课程建立上会比较吃力些，真想作的人要有思想准备。我我的曾经尝试和南京的TalenCamp按照第二条路来设计课程，但因为各类缘由暂时进展不太大。