Question

引入技术领导力，一条小的软件架构准则就有从根本上帮助软件团队成功的巨大潜能。考虑到这一点，我们需要解决的最后一个问题就是，如何让软件团队采用一个正好合适的软件架构方法，确保构建出结构良好的软件系统来实现目标，特别是各种复杂的非功能需求和约束。这个问题通常会变成，如何将软件架构重新引入软件团队的工作方式。

在我看来，软件架构最大的问题是它在与软件行业每天创造的新事物竞争。我见过世界各地数以千计的软件开发者，以我的经验，他们当中很多人对软件架构的思考还不够。尽管教材非常多，很多团队还是缺乏对软件架构的真正认识。

人们用于学习的时间和精力有限，但没时间通常不是团队不理解软件架构是什么的原因。我以前担任软件架构角色时，和很多人一样搞不清读过的软件架构书跟日常工作到底有多大关系。这种缺乏了解的情况日益严重，因为大多数软件开发者并不定期实践软件架构。你在自己的职业生涯中，架构过多少软件系统？

简单来说，即使所有软件团队都思考软件架构也远远不够。那么，我们如何让软件团队重新认识软件架构？

软件架构应该容易理解

作为经验丰富的从业者，我们有义务去教育别人，但也要一步一步来。要记住，很多人在接触软件架构时可能都不了解过去的相关研究。想想你看到和听到的关于软件架构的术语。你要怎么跟一个典型的软件开发者解释“逻辑视图”？当我们谈到“物理视图”时，指的是代码还是物理设备？在我们开始谈论架构描述语言1和评估方法2之前，开发团队中的每个人都要了解软件架构的本质以及不思考它的后果。软件架构的信息要具备可用性，立足现实。

1http://en.wikipedia.org/wiki/Architecture_description_language

2http://www.sei.cmu.edu/architecture/tools/evaluate/

这么说似乎很怪，但管理软件团队的人也需要理解软件架构的本质和必要性。这些年来，我合作过的一些团队的管理层会对团队说“别做软件架构了，赶紧写代码”。这种情况很多时候都源于一个误解：采用了敏捷方法，所有预先设计的做法就都应该被摒弃。这些软件开发团队通常承受着极大的交付压力，但一些预先思考不但不会成为阻碍，反而是有益的。

一些实用的建议

下面是一些向初学者介绍软件架构的实用建议。

1. 宣传教育

举办几次专题研讨活动，帮助人们学习和理解软件架构是什么。可以针对开发者或非开发者，这有助于确保所有人都有相同认识。至少，你应该留意下面几点：

软件架构是什么；

软件架构为什么重要；

你打算采取的做法。

2. 回顾架构

如果你定期回顾反思你的团队执行情况，为什么不直接在谈话的主题列表上加入软件架构？如果你认为软件架构没有得到足够重视，也许是因为你经常重构你的软件架构，或者在一些非功能特性上遇到了问题，那么思考一下你可以采用的软件架构实践。另一方面，如果你花太多时间思考软件架构或预先设计，也许是时候看看这个工作的价值，以及是否有任何实践可以被放弃或取代。

3. 完成标准

如果你对工作项目有“完成标准”，把软件架构也加进去。这有助于确保你以任何所需的架构模式、规则或非功能目标来考虑工作项目架构的影响和实现的一致性。

4. 分配软件架构角色

如果你的软件团队不思考软件架构，那么简单地把软件架构角色分配给团队内某个可能合适的人选也许可行，因为你明确地把对软件架构的所有权和责任指定给了一个人。把这个角色分配给多人在有些团队里行得通，但我发现，起初由一个人承担，然后随着团队经验的增加，再与其他人共享，这种方式更好。有些团队不喜欢“软件架构师”这个词，而代之以架构所有者3。不管你怎么称呼它，指导和合作才是关键。

3http://www.agilemodeling.com/essays/architectureOwner.htm

5. 架构培训班

光说还不够，怀疑论者要看的是架构并非大型预先设计。这也是我举办短期架构培训班的原因，一些小团队可以协作为一组简单的需求架构软件解决方案，制作数个可视化图表，并互相交流各自的方案。这让人们体会到预先设计并不一定意味着在非常低的抽象层次设计好所有东西，也提供了一种实践沟通软件架构的方法。

推动变革发生

对那些明白软件架构很好，却不知道如何将其引入项目的人而言，有一个比较常见的问题：

“我理解对软件架构的需要，但我们的团队没有时间实施，因为大家都忙于为项目编码。话虽如此，我们没有一致的解决问题的方法，诸如此类。我们的经理也不会给我们时间做架构。做架构，就没法编码。该怎么引入架构？”

为了理解软件架构对主动思考的需要，有几个问题值得一问。

1.缺乏软件架构造成了哪些问题？

2.缺乏软件架构在将来可能造成哪些问题？

3.这些问题是否有引发更多严重的后果（比如失去声望、业务、客户、收入，等等）的风险？

4.哪些事已经做错了？

有一件事我会告诉刚接触架构角色的人们，他们确实需要专门花一些时间在架构工作（大局的事务）上，但要与日常开发工作之间找到一个平衡。如果你所有时间都用来编码，就做不了架构。另一方面，“软件架构”花太多时间意味着你没写什么代码，可我们都知道漂亮的图表对最终用户毫无用处！

“我们该如何引入软件架构”这类问题没有一个简单的答案，因为它要求软件团队改变工作方式，只有当你完全了解团队的情况，才有可能。一般来讲，团队改变工作方式大致可以分为两类。

1.被动型：大多数团队只会在情况变糟的时候改变工作方式。换句话说，当且仅当有诱因时，他们才会改变。诱因可能是失败的系统部署过程中的任何事，或者严重系统故障之类的事情。在这种情况下，他们知道有些事不太对，可能因为管理层让他们日子不好过，他们也知道必须有所行动，改变这种状况。可惜，这种方式在软件行业里占了大多数。

2.主动型：有些团队则积极地改进工作方式。即使没有发生什么坏事，他们也能看到改进的空间，防止陷入上面提到的状况。讽刺的是，这些团队往往很优秀，并不需要改变，但他们非常清楚持续改进带来的好处。

回到原来的问题，团队确实想花一些时间在架构上，但并没有得到管理层的认可。也许管理层并没有清楚认识到这样做的好处或者不这样做的后果。无论怎样，团队都没有得到期望的结果。每当我自己处于这种情况时，我会采取以下两种方法之一。

1.以非常清晰和简洁的方式陈述当前的状况，如果不做出改变，会有哪些问题、风险和后果。通常你会向主要决策者、项目资助人或管理层陈述这些内容。一旦他们了解了风险，就能够判断，是否值得为降低风险付出改变行为所需的精力。这要求很娴熟的技巧，有时候也未必被接受，特别是刚接触到一个你觉得不正常的团队。

2.以身作则，发现并解决问题，包括缺乏技术文档、解决问题的方法不一致、架构层过多、不一致的组件配置等。有时候，在所有人了解付出精力得到的回报之前，最初改变的种子就要到位，有点像大多数人第一次看到自动化单元测试时的反应。

每种方法都有各自适用的情况，这取决于很多因素。回到原来的问题，有可能使用了最合适的方法，但要么消息很弱，要么管理层不认为值得花这个钱去降低没有专门“架构时间”的风险。对于这种情况，我会以积极主动、以身作则的姿态引入软件架构。只要找到并修复一个问题（比如多种配置方法，没有高层次文档，混乱的组件结构，等等）。我不是说要放下工具停工几个星期，因为我们都知道，想要说服管理层同意花三个月来重构太困难了。我的意思是，分解问题逐个击破，一步步改变处境。每天花几分钟在这类任务上，在你意识到之前，可能已经有所改观了。“请求原谅比得到许可更容易”。

软件架构的本质

很多软件团队都已经在使用敏捷和精益方法，更多的团队在朝这个方向走。因此，团队采用任何软件架构实践都应该产出真正的价值，否则就只是在浪费时间和精力。只有你能决定多少软件架构才合适，也只有你能决定如何最好地引导出你想在团队中看到的变化。祝你好运！