| |||||||||||||||||||||||||||
真正的成功，光靠对新东西的着迷是不够的，还需要开始提出各种问题。敏捷需要架构师么?架构师又是不是需要敏捷?
▲Coding the Architecture创始人Simon Brown
这几年来，对于好的软件设计，我们是不是忘掉的比学到的还要躲?浮现式设计真的就是坐在那里盼着最好的事情出现么?如果我们明天真的不再培养架构师了，我们说的这些又有何意义?我们如何不再郁闷，走向宁静?在今天下午的全球系统架构师大会上，Coding the Architecture创始人Simon Brown给我们分享了他的一些看法。
以下是精彩演讲内容：
大家上午好!首先，讲一下软件架构师的认知是什么意思?如果你是一个架构师，往往有人觉得做大型前端设计、懂UML就是架构师。
我不是一个很有力的架构师，不会画出大量的架构图解，我的工作不是做画大量的图。其实有很多的热门词汇来描述软件架构师的角色。最近听过一些热门词，比如说架构师是“业务技术战略家”，业务、技术、战略家三个词我懂，放一块我不懂了。我有一次开会，有人问我，怎么样把MongoDB放在当中，他们高层告诉我MongoDB是什么。有很多的热门词，热门词有必要的，用术语、用热门词。往往太多了，就忘了软件开发基本的知识了，我们离软件学问越来越远。所以我是一个软件程序员，是架构师，是团队一样。也喜欢编写代码，大家举手有谁喜欢编代码的。挺多的。
我们考虑架构师是什么地位。我入行的时候是一个工程师，是一个软件程序员，慢慢晋升到架构、团队领导的工作。我有两个很有意思的时期，在UML的时候，我最早开始做架构的工作，主要是画UML的设计图。6个月写UML的文档，对我来说我觉得是一种浪费。
我在一个大型的管理咨询公司服务，他们招我进来做软件架构师，每天也编写代码，他们不理解，让做软件工程师为什么要编写代码呢?在大型企业往往是事业的阶梯，你是一个高级程序员、架构师，慢慢升上去，离开了这个队伍，进入了管理团队，这是很令人遗憾的。大部分的技术人员，最好在这个团队里还是发挥作用的。在团队里面，很多时候英国一些公司，因为技术源做得好进入了管理层，公司反而失去了动力。
我有一个网站叫Coding the Architecture，觉得架构离不开这个编码范畴的。很多人说软件架构师是一个名片上的职位、头衔，拿到这个头衔工资高一点。但是这是一个角色，是慢慢发展才能进入的角色。
大家进入Linked讨论的话，说是一个高级程序员晋升到架构师，说我该干什么，有些人进入到架构师反而不知所措。
谁想做到敏捷?
有些人喜欢敏捷，敏捷是未来大的理想。软件开发做到敏捷，是很酷。但是，我觉得我们是不是忘了一些什么?特别是软件架构的时候是不是忘了什么?
我们讲一下敏捷这个词，敏捷有很多相关的热门词：自动测试、精简、瘦，这些都相关，而他们都是很好。其他表现、扩展性、安全、团队的共同目标，很多人忘了这些其他的重点。
很多人把敏捷强加在很多的名词前面。我看到很多都会把什么词前面都加一个敏捷，说卖什么东西就卖敏捷的什么东西，听起来很酷。到底什么是一个敏捷的架构师呢?敏捷的架构师是不是不用UML的架构师呢?这种概念有些时候没有什么意义，但是听起来很酷吧。
这是敏捷的架构吗?在我培训过程中，有人画图的时候用即时贴进行画图，这就敏捷了吗?架构在敏捷的方式当中，架构在什么位置呢?用不同的Skills时间框。按照项目的过程在不同的阶段进行不同的设计，这是不是也是一种敏捷呢?
很多人认为只是做了一个架构，希望最好的结果。很多人觉得敏捷是一个借口，做了敏捷看效果好不好。
很多人跟我说，我们不需要软件架构，因为我们做的是测试驱动开发。TDD就是一种测试驱动开发，但是跟软件架构不是一会事，TDD是大的代码，从基层的角度讲，架构从高层角度。
最后负责时刻，这个词我不太喜欢，很多人作为一种借口，迟迟不做决定，这就是敏捷，最后负责的时候做决定，往往最后的负责时刻成为不负责时刻。很多的敏捷书籍，要自我组织的团队是一个扁平式的组织，没有组长，大家通力合作，这个听起来很好，因为扁平式的合作更加快捷，但是有些时候这种团队不行，但是没有人告诉你有些自我组织的团队，他们可能有几个有经验的人，比如说有高级，如果把高级和低级放在一起自我组织不行了。有时候有些人说，你为什么对敏捷有这么大的意见呢?其实我喜欢敏捷，并不是要抨击敏捷，有些人觉得敏捷太多让我们觉得很酷的东西，但是忘了一些最基本的工夫。
我觉得我们应该要回顾一下，回顾也是敏捷的热门词。我觉得我们忘的东西比学的更多。在软件行业来说，学的不如忘的多。有多少人在项目当中还在用UML的?数量很少。在欧洲的比例也差不多，如果五年、十年前问这个问题，每个人都举手。今天用这个问题很少人举手。不是有什么取代它，而是很多人忘了它。
15年前出了一本书《颜色编码》，用颜色编码的UML的工作方式，这个很好，很多人忘了。因为用颜色可以清楚的做一些图解，还有CLC，类-责任-协作，很好的方式，可以做分析储存的分配，找一些人做了一块，找了一个用力，进行分解。满足用力的特点，跟每个类分配一些责任，同时找到不同工作中协作的过程。这是软件系统进行分解很好的方法。用团队分解，现在很少人用这个方法了。
边界、控制器和实体，这是系统结构很好的方法，面向服务的架构方法。同样还有基于组件的开发、面向模式的软件架构。整本书都会讲面向模式的软件架构，这种书出版很久了，虽然是一本老书，里面的内容在今天来说跟当时出版同样有意义，但很多人没有读这本书了。
Rational统一过程，是一种增量式很直观的过程方法。敏捷也是增量式的过程方法。Rational的统一过程是围绕架构做一个核心，以这个核心做各种活动，让架构不断的演变。
刚才跟大家突出强调了一些过去的方法，这些方法很不错的，不是让大家回去按照这个做，我们要实际一点考虑，看看老的工作里面有哪些经验教训和诀窍给我们用。觉得可用的话，可以在具体的工作里面可用一下。
这些经典的东西谁在教你?没有人教你，因为经典的东西看上去不酷。我们书架里面有书，有看板、有经义、有程序设计等。现在人不讲了，觉得没有意思了。
很多人是做软件架构师的，实际上没有搞清楚做软件架构师是干什么。我在伦敦工作的时候，招日招软件架构师，面谈看简历情况。这时有一个企业的架构师，描述他的工作，做得工作就是大企业里面做一个软件架构师，给自己加上一个实际上根本没有负责的头衔，让人听起来感觉很不舒服。
经常发生这样的情况，人们发现软件开发像接力赛一样，实际上解决方案的架构师会问一些情况，或者要求之后，会做一些架构把它以文件的形式记录下来，非常厚的文件，文件交给团队就跑掉了。
团队拿到文件之后，要负责把架构真正付诸于实施，我不喜欢这种方式，这个人做了架构跑掉了，团队不知道怎么做出来的，内容团队有问题的话，不可能问原来设计的人。我给它起了一个名字，AaaS，读音是屁股的意思，把架构服务交给团队不对的。就像接力赛一样，一个棒给下一个运动员就跑掉了，其实不行的。
项目的成功不仅仅是关注与实施，很多人认为实施好就行了，并不是这样的。
现在看到的图里面有非常多的图表，人们非常愚蠢的期待结果，做了价格，不知道能不能行通就丢给别人。有一次有人让我们来看一个项目，当时架构里面就一个软件架构师，做技术指导工作的。我看架构的时候发现了软件系统里面的问题、难处，其中有安全的问题，还有功能根本用不上，另外做了负载测试结果不好，文件的记载也不怎么样。这个项目不小，是战略平台的第一步，要先做了价格，未来几个月、几年把服务加在上面。
对我来讲，一个软件架构师，要杜绝PPT上列的这些问题。我觉得做文件记载非常重要，但是现在讲所谓的敏捷的软件架构设计，很多人不记录文件，敏捷的人不会把文件记录下来，根本不增值、只做增值的事情。当然厚厚一叠文件给别人也不行。我们需要提供文件，而且精简，不用太多，搞清楚问题就行了。
在英国以及在欧洲，我发现有些人根本不了解干什么，尤其是大团队里面，大家对决策不清楚，刚才Pinterest讲到团队扩展，团队扩展会带来一些问题，大的团队在一片混乱中工作，不知道自己在构建什么，而且不知道怎么样构建，根本没有蓝图，大家都是随心所欲，根本没有指导性的目标。出现这种情况的话，在这样一个混乱的系统里面，最关键的是把它停下来，在系统里面工作非常慢，无法扩展，没有任何安全感，感觉编码像一滩烂泥一样做不好。我希望编码非常清楚、有好的结构和次序做出什么。要打破混乱，有好的愿景，让写代码的时候知道方向，按照这个方向来走。原来哪些人做项目有很大的文件，就是让大家分享他的想法。但是如果这么多的文件，会太长没人看。既然没人读你的文件，初衷没有得到实现，大家也是失去了方向。
现在我们做敏捷了，有些文件可能在白板上画一些东西，但是别人不知道画什么，就像无稽之谈一样，没有共享的愿景，别人画的东西搞不清楚。
给大家举一个例子，来自于有一次我看到的系统的图示，我觉得完全没有意义，根本不知道这里面硬件还有软件以及不同的节点发挥什么作用。这个比较典型，一片混乱搞不清楚做什么。所以我们必须要把我们所工作的方式可视化。我们看敏捷、看板、故事强。用易贴纸在墙上，就知道流程是什么样的。我们不可能系统用图的方式来做。还是要考虑用UML来画出来。
以上是我演讲的第一部分，作为软件架构师对行业感到的挫败感。
我们希望团队成员共享愿景，知道发展方向怎样，很多时候在公司里面会请一个软件架构师，会成为这个架构师的头头。开发人员接受架构师的指令，团队就是这样工作的。我们感觉软件架构师在象牙塔里面使令，在开发团队做的事情没有任何交集。软件程序员不会理会架构师的建议，觉得建议是一派胡言，用不上，要避免这种情况。
怎么做呢?
我们请一个软件架构师，把他当成领导安排工作，希望与团队合作，能够提供指导，提供相应的辅助性的工作。要把软件架构师和软件程序员放在一起，缩小差距，慢慢实现共鸣，这样的话非常有意思了。在一个结构里面大家可能都是软件架构师，这是一个非常乐观的情况。不让他们都成架构师的话，缩小差距，慢慢也会实现工作中的互联互通。
我们要请一个软件架构师选什么样的人?
T型的人，首先要有深度，T下面的一竖，有扎实的技术功底，至少懂基础的语言来做。打交道知道技术怎么回事才知道技术。T下面的一横，要知道不同的方式，知道不同的结构，解决代码问题、扩展问题，要看不同的系统怎么做出来。Pinterest两位发言人讲得非常有意思，可以从那里学出来。架构的词英文到底来自于什么意思?最原始的意思是建筑师。原来建筑师拿一些石头、砖头盖房子。架构师也是一样，我们也是盖东西，成为这方面的大师、专家，成为通才化的专才，是软件架构师应该有的角色。有专业的专才同时有不同的领域。
有一位英国的先生jasongorman加入了软件的运动，在微博里面写，我现在不写代码了，觉得行业里面资深的人有奇怪的想法，已经很资深，不写代码了，会不会雇一个不会编码的架构师?
现在看到的是从比较高端的角度界定一下软件架构师做一些什么东西，保证了解要求、组织的约束到核心的技术、设计软件、评估软件设计，确保用得上至少信心满满说肯定用起来。编码，软件架构师核心的工作。软件架构师不是做一件事情就固定不动了，遇到新的要求就要不断的演进，根据不同的需求满足不同的变化。质量保证也非常重要。教练和指导，这是之前讲过的，找一个架构师与团队协作，提供辅导的机会带领前进。
软件程序员看一些代码、测试、软件的编制，架构师不太一样，架构师要后退一步看看全局。所以这个时候并不只是看代码级别的内容，为什么呢?想象一下有一项要求，做一个软件架构来解这个要求，怎么做?要把要求进行分解，从功能性和非功能性分解。所以，可能在环境当中有一些局限性，在工作大部分的情况下，技术选型有限制许可证和软件等都有一些局限性。不知道架构有哪些局限性，而且有一些原则要进行。有些要在整个软件开发当中，从始到终遵守一致的原则。解决问题有不同的方案。从编程语言到选择技术案例。找到一个最好的方法，找到最好的选择。不同的要求，不同的局限扔到一个盒子里，找出最合理的一项。至于在软件编成的过程中，敏捷可以看到很多时候大家不用UML的工具，我也会用UML的工具，用它来做一些图解，需要一些正规的流程图，可以用它来做流程图。但是在设计软件的时候可能就不会做这么正规的流程图，可能会用白板、易贴纸等。如果三四个人挤在我的电脑前用UML工具，就很麻烦，但是可以在大的白板前面一起合作就很简单了。
我很喜欢画画，很多人不喜欢画画，不用UML，我是怎么画画的?基本上按常理出牌，画一个高层的概念，把它分解，在分解筐子里进行考虑，分解数据服务、数据库、架构等。在每个服务器又把服务器进行分解。更多的细节可以按不同的类来分解。所以这叫做C4的方法，是非常有效的草图法，可以很简单非常精益的做出非常好的草图。
为什么说架构师是一个总的建筑师呢?如果是你会不会把系统进行编码?是的话还好，如果据的编码不合胃口就麻烦了。如果架构师不懂背后的编码，会问出这个不合理的问题。
文件很麻烦，有时候会做厚厚的技术文档，很快过时。从另外一个角度来看，从精益角度来看文档说明。我们把它看成旅行手册，如果看任何的旅行指南，会有地图告诉你怎么走，这就是我们的代码基础了。有这个草图就是我们的地图了。我们看一下景点，哪些地方不可错过要看一番，要看有历史文化的景点。比如说这个地方怎么慢慢演变到今天的局面的，使用的信息，怎么建立和配置我们的系统。所以我们说精益想敏捷要减少浪费、增加价值。关键是要言简意赅把要说的东西说出来，而且要增加价值。如果画出一些类的图解。本身看代码就能知道，本身也能够理解，他们是程序员，看代码就看得懂了。所以要描述一些代码没有的东西。通过示意图像地图一样，帮助程序员或者别人通过你这个找出文档当中所要的东西。
这是不是大型的程序设计呢?其实并不是的。如果你看十年前，我们会有一些非常糟糕的方法。另一方面，我们有敏捷的方法，比如说极端的编成，Scrum等，这是演变性的价格设计方法。但不幸的是，有些人觉得两者都不做是最好的，左边前期什么都做好，另外一个极端什么都不做最好的。实际上我们不一定要走极端，可以两者取其中。比如说像RUP统一过程，这是两者之间的做法。是轻量级的，同时也是增量型的，对架构不放过。我的答案是刚好够用。做的前端设计是刚好够用，符合你的项目，而且是合理的，这是非常好的项目，这是一个好的指引，但是并没有告诉你，多少才算是够用，这就是我们回答重要的问题了，多少才是够用呢?
Scott Ambler是在IBM工作的人，倡导敏捷包，有一个网站倡导一句话可以概括了，你的架构应该建立在要求上，要轻装上阵。轻装上阵是一个敏捷要刚刚够用，同时要用实实在在的经验和实验来证明你的架构。
什么叫做实实在在的实验呢?用一个圆形和概念证明的方法，做一个薄薄的切片，把软件切出薄片测试软件的功能、扩展性。你怎么知道应该做哪一种的概念原形证明呢。必须要知道，哪些部分在架构上是有重要意义的。架构当中哪些是重要的，进行这些测试。我们围绕着核心架构有很多的其他内容，我们必须要把核心的架构搞对。这就回到我们说一定要把主要的风险排除在外，消除我们的风险。
有些时候发生了风险就会有不利的效果，当然要在软件的项目当中避免这种风险发生。当然，风险可以量化的，只要把它在一个概率和影响的举证就可以进行量化了。如果是非常低概率的风险以及非常小影响的风险，只要知道就行了，不需要做什么。如果有一个风险是高概率、很可能发生的风险，而且影响破坏很大，这种情况下，高影响，整个系统架构要重换。整个风险因素就要提早进行考虑。所以很多不同的风险优先次序不一样。我发现一个问题，软件团队不太善于列出风险，觉得很无聊，把风险给写下来，这个可以解决。在我的培训当中，网站里面有一个内容，有一个风险的脑力风暴。让他们去识别风险，会画一些草图，让他们就这个架构草图放在墙上，然后把团队、程序员、测试员，所有的人员坐在一块，让它看架构草图。你们觉得系统有什么风险?哪里有风险?升级性、扩展性、技术的选型还是可用性?每个人有自己的想法，把这个想法汇总在草图上，这样的话可以视觉化的通过贴纸的形式看到大家的想法。所以风险也可以是主观性的。
当然，我们找到风险之后，必须要处理、缓解风险，不是找到风险就完了。我们举一个例子，什么叫风险。我在丹麦去年开了一次会议，他们说，我们对敏捷项目的一个回顾，Linda Rising会有不断的回顾，发现什么问题的时候，会把问题写在一个卡片上，粘在墙上，不同颜色的卡片代表不同的感受，有些是快乐的卡片，有些是挑战困惑的卡片。红色的卡片是愤怒的卡片。当他们觉得问题是非常愤怒就写一张红卡片。Linda Rising把所有的卡片铺在地上，一边是起点，一边是终点。在项目的终点时，用技术用得实在很恼火，但是应该在项目开始提出来，而不是终点找到痛点。
我今天讲得是软件架构师的过程和角色不是一回事。软件架构师的角色根据不同的团队各有不同，角色不一样，有个人写了一本书《从混乱到自组团队》，列出不同风格的团队，有的团队是混乱型的，有的是自我组织型的。不同团队有不同的领导力，在混乱团队当中有非常严明的领导把混乱加以控制，但是在自组团队当中每个人都可以是领导，当然中间有不同的阶段。这就是软件架构师的角色，这个角色在团队当中跟不同人之间的关系不一样。软件架构师的过程又不一样。一方面前期设计，另一个极端做了之后也不管，看最后的效果如何。如果想把这两个极端用图描绘出来的话，刚刚够用的架构刚好处在中间。并没有大型的前期设计，没有什么都不管，讲的是中庸之道。架构有哪些结构的重要要素，在前端设计要关注的。这时前端要识别主要的风险、消除风险。但是要有共同的愿景，让团队围绕这个愿景合作。在自组团队每个人可以做领导。
敏捷软件开发的项目是不是需要软件架构师呢?我的答案是肯定的。你的项目就是敏捷或者不同的结构，但是架构是不可回避的。就算敏捷的项目也可能是很复杂，也可能有高安全性、高扩展性、高性能的要求，这些都是希望从架构师的角度解决的。
或者我们可以把这个问题反过来问，敏捷性怎么影响到软件架构行业的?很多公司做大型的前期设计，设计上带来系统分析、带来瘫痪，想得特别多，敏捷性搭不上的。有什么建议呢?如果团队处于混乱之中，没有共同的愿景，回到一开始，重新界定一下到底软件架构师做什么的，至少团队中有一个人是技术的领导者，他来确定方向。你规划出他到底做一些什么东西。比如说八个盒子，每个框里面到底哪些工作是怎么做的。另外，软件架构师中一些手工活，别老用电脑来做，一些草图用手里画，画的比较简单一点，贴在墙上，要想敏捷行动要快，行动快的话和别人很好的沟通，很好构图的方式就是画草图。我们要做的软件系统是发挥作用的，能够工作的、能够扩展的，能够不断的升级的。
作为一个软件架构师，实际上就是一个技术方面的领导者，要非常积极主动，带动团队而且以身作则。如果看到一个问题，直接上去解决就行，其他人就会效仿你，看到问题也会解决。
我们要为未来做好准备，未来有其他的软件架构师，要提供管理、培训，确保未来成功出师，能够培养出来。不管做什么，只要适合你就行。因为我们面对不同方案、不同技术，要做的是选择一个用起来最舒服，发挥最大效用的，所有的团队都一样。像敏捷性是热门词汇，很吸引人。但是敏捷对于你来说没有四海而皆准的方法帮你解决问题。
我就讲到这里，谢谢各位!
(来源：it168网站原创 作者：景保玉)
京公网安备 110105001605号