软件架构师的理解与摘录

1.王滔谈软件架构师和程序员的区别  http://www.cnblogs.com/wangtao_20/p/3242987.html

好的程序员做不出好的软件设计

本文由“外刊IT评论”网(http://www.aqee.net/)荣誉出品

你不能看到一个程序员还不错，就把他推到系统分析师、软件设计师或软件架构师的位置上。

如果你在团队或公司里寻找一个能胜任软件架构师或设计师这样重要位置的人时，首先出现在脑子里的想法通常是在程序员中选一个最好的。别这么干。这样的位置不是随意的找个不错的程序员就能胜任的。把你最资深的程序员晋升到这个位置也未必就合适。

乍一听你可能感觉荒诞。为什么我不能让一个程序员去做系统设计呢？毕竟，他们是设计程序的，不是吗？的确是的，没错。但你要明白的事情是，设计软件相对于编写程序，它需要的是一套完全不同的技能。

让我们来看看为什么一个好的程序员就未必可以做一个好的软件设计师。但首先，让我们来问问自己一个问题，是什么让一个程序员变的优秀，甚至杰出？要想成为一个好的程序员，你需要有能力实现真实世界里重要的软件。只能够写出一个简单的文本编辑器是远远不够的。

为了能做到可以解决重大的、复杂的编程问题，一个程序员需要在某个特点的编程语言上进行数年的经验积累。也就是说，为了能熟练的使用这种语言、熟悉这种语言的各种特色，他必须专注于这种语言。问题就在这儿。

对于只有锤子的人，他能解决的问题就是钉钉子

如果你专注于一种语言，并能做到精通掌握，那你遇到的问题模式很可能就限制于跟这种语言相关的领域。简言之，如果你懂PHP，那所有的问题都基本上是跟 Web开发相关。相同的道理，如果你全部的知识都集中的Java上，那你对所有问题的解决思路都会沿着面向对象的方向，即使是使用过程式编程对于解决你的问题会更优的情况下，你也会如此。

一个程序员，只懂得一、两种编程语言，这会严重的限制他的解决问题的能力。例如，如果你的编程语言是C语言，对于手头出现的问题，你绝对不可能想出一种面向对象的解决思路，因为你的编程语言不提供这样的语言特征。跟Haskell程序员不一样，C++程序员不可能想出函数式解决方案。你的编程语言里提供了结构体和枚举类型与否，会严重的影响你剖析一个问题的方式。如果你使用的语言的能力很弱，或你只知道少数几种语言，你解决问题的能力相应的会被削弱。

语言塑造了我们的思维方式

有人说，我们的语言塑造了我们的思考和认知这个世界的方式。我基本上认同这个观点。当一个人的母语里的名词都有性别之分时，他一定不会同说其它种母语的人那样一提起“警察”这个词就基本上认为是男的。当一个人的母语里对蓝色和绿色不区分时，他对世界的感知会和那些有区分的人的感知大不一样。

如果我们回首中世纪学校的三学科，它们被描述为：语法解决概念和对象如何在书写和话语中被表现，用逻辑对它们进行分析，最终以修辞为目的同他人交流。对于我们来说，编程语言也有语法。如果我们的编程语言不够强，我们对事物和概念的认识以及对如何表达它们都不会有完整的视野。

语言，我们用来跟人们、跟计算机交流的功能，明显的影响着我们的思考方式。我们对语言知道的越丰富、越多，越能帮助我们提高解决问题的能力。

那么，什么样的人更合适？

那么，一个在某一两种编程语言里具有专长的程序员，在当他解决一个问题时，会存在一定的局限。他会局限于他使用的语言允许他做的事。因此，他不会成为一个好的软件设计师或分析师。

如果我们不用这些优秀的程序员，谁又能担当软件设计的任务呢？当然不会是那些完全不懂编程的人了。我们需要的是一种通才。一个优秀的软件设计者必须通晓过程式，面向对象式，函数式，以及逻辑式编程语言—还包括各种优秀的软件开发方法论。他不能只熟悉一种方法模式、像一个专业领域人员那样。当然，他自己并不能写出复杂的程序，因为他的知识太宽泛。尽管如此，他却能正确的判断出怎么样的设计才是一个正确的解决方案。如果问题是处理一个钉子，他会找来一个熟练使用锤子的人；如果问题是处理一个巨石，他会叫来爆破部队，而不是让你徒劳的用锤子白费力气。

 

 

联想到一本书里面提到(子柳写的《淘宝技术这10年》)，我把大致意思归纳如下：

 

在系统的发展过程中，架构师的眼光非常重要，作为程序员，只要把功能实现即可，但作为架构师，要考虑系统的扩展性，重用性，对于这种敏锐的感觉，有人说是一种"代码洁癖"。淘宝早期几个架构师具备了这种感觉。

虽然个别架构师具备了"代码洁癖"，但淘宝前台系统的业务量和代码量还是呈现爆炸式的增长，业务方总是在后面催，开发人员不够就继续招人，招来的人根本看不懂原来的业务，只有摸索着在"合适的地方"加一些"合适的代码"，看看运行起来像那么回事后，就发布上线。这样恶性的循环中，系统越来越臃肿，业务的耦合性越来越高。开发的效率越来越低。借用当时流行的一句话"你写一段代码，编译一下能通过，半个小时就过去了;编译一下没通过，半天就过去了。“
在这种情况下，系统出错的概率也逐步增长，常常你是修改了商品相关的某些代码，发现交易出现问题了，甚至你改了论坛的某些代码，旺旺又出问题了。这让开发人员苦不堪言，而业务方还认为这些开发人员办事不力。

由于当时从硅谷空降了一位技术高管，他告诉我们一切要以系统稳定运行为中心，所有影响系统稳定的因素要解决掉。每做一个日常修改，必须对整个系统做回归测试一遍。多个日常修改如果放在一个版本中，只要一个功能没有测试通过，整个系统都不能发布。我们把这叫做火车模型：任何一个乘客没有上车都不能发车。这样做的后果是，新功能上线速度慢了，所以当时明显感觉到业务方的不满。压力很大。
由于把每天晚上都需要做一次整个系统的回归测试，在这种要求下，整个系统很庞大，我们不得不对这个超级复杂的系统开始肢解和重构。比如把用户信息模块拆分出来，叫做uic,它只处理最基础的用户信息操作：getUserById，
getUserByName等。

系统进行拆解后，相互之间互补影响，不会因为一个用户中心程序出错，交易无法使用。

新做的淘宝旅行，淘宝彩票，只是在交易流程数据需求上不同。但是用户信息是跟淘宝主站类似的，如果当时能够做系统拆解，就不用重新做一遍,调用uic中的信息即可(现在的淘宝旅行，淘宝机票是分开展示的就是这个原因，当时为了不给淘宝主站添乱，单独重新写了两套系统用于旅行和机票)

 

 

2. 李智勇 谈 从程序员到架构师的方法与逻辑 发于CSDN http://www.csdn.net/article/2014-07-28/2820883

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

架构师是什么？

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

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

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

 

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

 

其他的需求呢就是感觉上肯定有，但暂时说不清楚

基于这样的简单提示，长做程序的可能脑子里会立刻冒出来无数东西，比如：

 

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

 

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

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

 

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

 

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

选定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按照第二条路来设计课程，但由于各种原因暂时进展不太大。