【专访】拥有16年从业经验的软件架构师，他对这个行业的发展有何看法？在8月份的ArchSummit大会上，笔者与大会的讲师之一，来自英国的SimonBrown进行了简短的交流，了解了他眼中的敏捷、架构师以及软件行业的发展。SimonBrownSimonBrown是泽西岛（海峡群岛）的独立顾问，网站CodingtheArchitecture的创始人，他将自己描述为编写代码的软件架构师和了解架构的软件开发人员。Simon在Microsoft.NET和Java平台上开发大型项目有很多成功经验。他现在还是欧洲论坛、讲座等的定期演讲者，内容涉及软件架构及其在现代软件开发团队中的作用。他也是《面向开发者软件架构》的作者，该书目前由Leanpub出版。他目前还在编写代码。以下为采访实录。：嗨，西蒙，感谢您接受采访！之前看到你分享的话题，提到团队在实施敏捷的时候，一定要保证团队中有足够多的优秀工程师。你是否经常遇到在团队不成熟的情况下盲目实施Agile的团队？西蒙：哦，是的，这基本上是常态——不幸的常态。你看，敏捷宣言去年已经10岁了，它作为一种哲学已经存在了足够长的时间。大公司希望实施敏捷，因为它透明、可交付、成本效益高、节奏快，并且有持续的反馈。听起来不错。但是很多实施敏捷的团队都会遇到一个问题，这也是我经常被咨询的问题，就是对项目和文档管理失去控制。如果你看Scrum，它提供了很多角色（配置文件），但它并没有提到太多关于如何操作项目的具体实践。敏捷流程还有很多其他问题，人们不知道应该关注什么；他们过多地关注技术，却忘记了很多基本的东西：安全性、可扩展性……他们开始在没有做出决定的情况下做出决定。做事闷闷不乐。我最近遇到一个这样的团队，他们来找我说，好吧，我们4个月前开始敏捷，我们做了很多冲刺，然后我们有一堆技术债务，现在我们一切都需要重构.如果我问你，如果他们一开始就想过，他们现在就不用面对这样的问题了。然而，这样的例子太多了。:那么，如何确保在团队中安排能够看到全局的人，例如架构师，以避免出现这种情况？西蒙：假设你有一个6人的团队。我们应该有安全需求、性能需求、可扩展性需求，或者其他复杂的功能需求，但有时我们会忘记这些需求。因此，团队中需要有人确保所有人都按照上述要求执行。这是单点技术领先。当然，您可以让多个人分担这项责任，但大多数团队都不是这样工作的。总之，有这样一个人的存在，就是保证团队成员在规定的范围内行事。:顺便说一下，有很多英国球队处于这种混乱状态吗？西蒙：哦，是的，大多数团队都是。其实全世界都一样。:之前看过你的博客，说不同的团队和工程师对架构师有不同的定义。但总的来说，架构师应该有一些共同的特点吧？比如职责和能力。您认为“建筑师”应该知道和做什么？西蒙：嗯，“建筑师”这个词本身对不同的人有不同的含义。如果你查一下“建筑师”的定义，会有很多不同的定义。有一个组织叫IASA，InternationalAssociationofITArchitecture，他们以前叫InternationalAssociationofSoftwareArchitecture，后来改了名字，希望把整个IT领域的架构定义统一起来。给一个东西下定义总是充满争议，但我觉得人们没必要为一个词那么纠结。IASA的人曾经定义过BusinessTechStrategist（业务技术策略是）的职位——拥有这样的职位意味着什么？当然，我也想创建一些被广泛接受的定义，但我认为更重要的是在一个团队中，组织定义优先。我们首先定义我们需要做什么，我们有什么职责，然后将每项职责分配给指定的人。这完全是根据团队的需要来定义的。:你认为像你这样独立工作的架构师和那些专注于产品团队的架构师有什么区别？Simon：虽然我是一个独立的架构师，但我和团队一起工作。如果说有区别的话，其实就是面向客户的团队和产品团队的区别。相同的责任，但不同的优先级。如果你为客户做系统，那么需求就相对固定了。但是如果你自己做产品，就不一样了，你在第一线，做出关于产品应该如何工作的各种决定；您需要考虑可扩展性，以及构建时可能面临的变化。:那么，您从1996年开始从事这个领域，到现在已经16年了。你有没有觉得自己长得特别快？西蒙：哦，我经历了一段极快的负增长时期（笑）。刚拿到架构师这个职位的时候，我很迷茫，不知道该做什么。那时候我天天画UML图，边画边想，嗯，我从一个coder变成了一个diagrammer。这感觉不对。它们之间有什么联系？我觉得自己处于退一步的状态。但后来我发现，要想看到更大的世界，就要退一步。多年来，我承担了很多项目，包括模块设计、组件设计、服务设计等等。最后，决定成败的是小细节。如果你搭建了一个系统，它的性能不是很好，你需要一个有经验的人来帮你分析其中可能存在的问题。总而言之，有很多前进和后退，我觉得整个行业都是革命性的。我还在学习，安全机制是怎么工作的，系统的交互机制，有很多新的东西，云计算，新的web元素和服务……要学的新东西太多了。置身于软件行业的大潮之中，并不是一件容易的事。终身学习。:那么，您认为软件领域在过去两三年内变化迅速吗？西蒙：当然，非常快。:与10年前相比？西蒙：我觉得10年前的行业发展非常快。那时候有互联网泡沫，我当时在搞Java，也遇到了很多新的热词：Web、企业级Java、JavaBeans、Servlets、JSP、应用服务器、集群……在那个时候，Java领域的变化也是极其迅速的。后来，Java逐渐放缓，.NET重新崛起；现在的云计算其实也是一样，亚马逊有elasticcloud，VMware有CloudFoundry，还有很多新的平台出来……其实每个时代都非常快。:好的，最后一个问题。你自己知道很多知识，你也提到架构师应该是T型人才（注：即在某一方面的技术专长，以及各方面的技术精通）。那么，所有开发人员都应该朝这个方向发展吗？西蒙：理想情况下，应该如此。:那么对于那些只会写代码的专业人士来说，未来还有发展空间吗？西蒙：哦，当然有！我们谈论敏捷哲学中的无所不知的专业人士。在理想的世界里，每个人都是平等的，每个人都知道如何做决定，如何照顾各种建筑环境，以及如何制作东西。然而，我们在现实世界中。上面提到的事情是很难做到的。现实情况是，你很难找到什么都懂的专业人士，能写出好代码的专业人士已经非常难得了。你有什么样的人，什么样的团队，决定了你能做什么，怎么做。如果您的员工只想专注于编写代码，他们不在乎是否必须提升一个层次才能看到更宏观的世界，这很好，很好。不要强迫他们做他们不想做的事情，不要强迫他们做决定。最有可能的结果是，即使你逼他们，他们也做不好。所以，让每个人都发挥自己的长处吧。Simon在大会上分享的PPT可以在线查看：-沮丧的架构师-Howtodesignasecurearchitecture下面是英文采访记录。#p#：关于您今天上午的会议的一个简短问题。所以我的解释是，当团队中没有足够多的优秀人才时，团队不应该盲目地采用敏捷。你总是看到这种情况吗？西蒙：是的，不幸的是，总是这样。敏捷宣言去年庆祝了他们的10周年，所以你知道敏捷已经建立了很长时间。大公司希望采用敏捷，因为它的透明度、可交付成果、预算、快速行动和获得反馈。所有这些听起来都很漂亮。人们在走向敏捷时都在为指导而苦苦挣扎，所以我经常遇到的一个问题是，好吧，我们正在采用敏捷，但我们在项目管理和文档评估方面苦苦挣扎。而且，如果您查看Scrum等框架，它们会为您提供配置文件和很多东西，但很少提供有关如何运行项目的实践。敏捷过程还有其他方面，人们不太了解他们从事的是什么，他们把所有的焦点我们在技术上，但他们忘记了基础知识：他们忘记了安全性、可扩展性，他们停止做决定……他们只是匆匆忙忙。我最近遇到了这些团队，其中一个团队过来说，我们在4个月前采用了敏捷，我们一直在做冲刺，但现在我们有很多技术债务，我们需要重新架构一切。如果他们提前想到，也许他们一开始就不会落入那种境地。这非常非常普遍。：那么你如何确保当一个可以从上到下看到的人进来时，这些事情不会发生？西蒙：想象你有一个6人的团队。如果我们有安全要求、性能要求、可扩展性或任何其他复杂的功能要求，有时我们都会忘记它们。需要有一个角色来确保人们遵守这些要求。这是技术领先的单点。当然你可以分担那个角色，但大多数团队的工作方式并不像那。所以这是关于让团队中的某个人退后一步，以确保事情按照要求进行。：只是一个简短的问题，英国的大多数团队是否都有这种混乱的行为？西蒙：是的，大多数团队。老实说，全世界都一样。：您在很多帖子中都提到过，不同的团队和工程师对“架构师”一词有不同的定义。但是，在任何一种分类下，任何定义为“架构师”的人都应该有一些共同点，要么是他们的职责，要么是他们的能力。你能简要描述一些广义架构师，他们需要知道什么以及他们需要做什么吗？西蒙：这是一个有趣的问题。建筑师这个词对不同的人来说意味着不同的东西。事实上，如果你仔细看看架构师的意思，又会有很多定义。有一个机构叫IASA，就是国际IT架构协会。这y以前称为国际软件架构协会，但他们更改了名称，因为他们想为所有IT架构提出一个定义。试图给出一个定义是有争议的，但我的观点是人们不需要为流行语而烦恼。IASA的人，他们曾经有一个商业技术战略家术语，这实际上没有意义。我绝对愿意创建一些众所周知的定义，但我认为更重要的是，在敏捷团队中，组织的定义是第一位的。我们必须定义角色，列出职责，并确保至少有一个人在做。它真的应该是一个团队一个团队的角色。Eachteamshouldhaveanarchitect.:你认为像你这样独立工作的架构师，和那些在特定产品团队工作的架构师，有区别吗？Simon:好吧，我是独立的，但我倾向于团队合作。角色一都一样，只是优先级略有不同。如果您正在为客户构建东西，那么需求可能不会有太大变化。在产品团队中，这是一个不同的角色，因为你就在第一线，你要决定你如何做事，你必须研究可扩展性，事情可能会如何改变。所以你开始了你的从1996年开始从事IT工作。至今已有16年。你有没有经历过你觉得自己有了很大飞跃的时期？西蒙：我确实经历过大幅倒退的时期。当我第一次担任建筑师的角色时，我不确定自己需要做什么。我在画UML图，我想，好吧，我已经从编码跳到画图了，这是不对的。这些东西怎么联系在一起的？我想我是在退后一步，但后来我意识到你必须退后一步才能看到更大的图景。我一直在做不同的项目e年，所以模块设计、组件设计、服务设计等等。实际上，所有这些微小的事情都会帮助您成功或失败。当你构建了一些东西但表现不佳时，你需要一些有经验的人来回顾可能发生的事情。这是很多来来回回，我想说这是一个革命性的职业。而且我还在学习。安全机制是如何工作的，使用事务弧系统，那里有很多技术，云，所有的网络东西，服务……有很多东西要学。它在软件趋势中扮演着艰难的角色。很多东西要学。永远不要停止学习。那么你认为那2-3年里事情变化得更快吗？西蒙：绝对快是互联网泡沫，那个时候我在做Java，各种流行语来了：web，enterpriseJava，JavaBeans，servlets，JSPs，applicationservers，集群……那是Java行业的一个非常快速的时代。Java现在放慢了速度，.NET开始了，如果你看看像云这样的东西，它也发展得很快。Amazon有弹性云，VMware有CloudFoundry，平台不断涌现……它总是在快速发展。：好的，所以你知道很多事情，你提到了T型架构师。是否所有的开发人员都需要朝着那个方向努力？Simon：理想情况下所有的开发人员。：那么那些只会编码的专家，是否还有空间留给他们？Simon：是的。尽管在敏捷中我们谈论的是广义专家，但在理想世界中，每个人都是平等的，他们可以做出决定、照管构建环境并一起构建事物。在现实世界中，这很难。真的很难找到广义专家。所以在现实世界中，你总是需要那些只会编码的专家。这取决于团队和你拥有的人。如果您的员工只想编码，他们会不关心大局，这很好。不要强迫他们做他们不想做的事情，比如做决定。他们无论如何都会做得不好。把他们留在那里，利用他们的专业知识。
