查字典图书网
查字典图书网
要成为一名软件架构师，绝非一夜之间或一次晋升那么简单。这是一个角色，而不是一个级别。这是一个循序渐进的过程，你会逐渐获得这个角色所需的经验和信心。“软件开发者”这个词很容易理解，而“软件架构师”则不然。下面是我认为构成软件架构角色应有的内容。注意，我这里说的是“角色”；它可以是一个人，也可以由团队共同扮演。 1. 架构驱动力 这个角色首先要理解业务目标和管理架构驱动力，其中包括需求（功能性需求和非功能性需求）和环境的限制。软件项目经常纠缠于询问用户需要什么功能，却很少问他们有哪些非功能性需求（或质量属性）。有时候利益相关者会告诉我们“系统一定要快”，这太主观了。非功能性需求和限制往往对软件架构有巨大的影响，因此明确地将其纳入软件架构的角色，可以保证它们被考虑到。 2. 设计软件 设计软件的过程是软件架构角色的一部分，这一点应该在意料之中。这涉及要理解如何解决架构驱动力带来的问题，创建软件系统的整体结构，并为交付设定一个愿景。不管你想做到多敏捷，你可能都需要花一些时间去明确思考架构要如何解决利益相关者提出的问题，因为你的软件系统自己搞不定它们。 软件设计的一个关键部分是技术选择，这通常是一个有趣的练习，但也有一定的挑战。例如，有些组织有一份允许使用的技术清单，你只能从中选择，有些组织则规定不允许使用特定许可的开源技术。接下来是其他所有因素，比如成本、许可、供应商关系、技术战略、兼容性、互操作性、支持、不熟、升级策略、最终用户环境，等等。这些因素掺杂在一起，常常会把选择一个富客户端技术之类的简单决策彻底搞成一场噩梦。需要有人负责这个技术选择的过程，这完全属于软件架构角色的职责范围。 3. 技术风险 到目前为止的内容可以帮你专注于构建好的解决方案，但并不能保证成功。把最好的设计和最好的技术简单地拼凑在一起，并不意味着整个架构就会成功。你选择的技术是否真的奏效，也是个问题。很多团队都有“做不如买”的战略，为了可能会节约成本而去使用一些（商业或开源的）产品。然而，很多团队也因为听信供应商网站或西装革履的销售人员的宣传，结果遭了殃。似乎很少人会问技术是否真的以设想的方式工作，能证明的人更少。 技术选择其实就是风险管理，当复杂度或不确定性高的时候降低风险，有利可图时再冒点险。所有的技术决策，在做出选择时都要把全部因素考虑在内，这些技术决策也需要评审和评估。这可能包括一个软件系统所有的主要结构单元，下至在开发过程中引入的库和框架。 你要问自己的问题是，你的架构是否“管用”。对我来说，一个架构如果能满足非功能性需求，在给定的环境约束下有效，能为其他代码提供必要的基础，作为平台能解决潜在的业务问题，那就是管用的。软件最大的一个问题就是，它复杂而抽象，很难通过图表甚至代码本身可视化一份软件在运行时的特征。此外，我并不总是相信自己第一次就能做好。当然了，说不定你可以！ 在整个软件开发的生命周期中，为了有信心让所构建的系统在交付时能正常工作，我们会进行多种类型的测试。那为什么不对架构也这样做？如果能测试架构，我们就能证明它是管用的。如果可以做得尽可能简单，我们就能降低项目失败的整体风险。架构师应该像优秀的主厨一样，品尝自己生产的东西。概括地说，就是主动发现、减轻和承担高优先级的技术风险，这样才能保住你的项目和工作。 4. 架构演化 很多时候，软件先被设计好，然后交给开发团队，实际上在把软件开发当作接力运动来处理。结果适得其反，因为这样的软件架构需要照顾。得有人看着它，在整个交付过程中依据不断变化的需求和团队反馈来对其演化。如果架构师创建了一个架构，为什么在整个交付过程的其他时候不自己拥有和演化这个架构？这关乎持续的技术领导，而不是仅仅参与生命周期的开始阶段，然后泰然处之、袖手旁观。 5. 编写代码 我认识的大多数最优秀的软件架构师，都有软件开发的背景，但由于种种原因，许多组织并不认为写代码是软件架构角色的一部分。做一个“实践派软件架构师”并不一定指涉足日常的编码任务，但确实意味着你要持续地参与到交付中，积极地帮助引导和塑造它。说了这么多，为什么日常编码工作不应该是软件架构角色的一部分？ 许多软件架构师都是构建大师，所以经常练手是有意义的。此外，编码为架构师提供了一种与团队分享软件开发经验的方式，从而帮助他们更好地理解如何从开发的角度看待架构。许多公司都有阻止软件架构师参与编码工作的政策，因为他们的架构师“太宝贵了，不该承担日常编码工作”。这显然是错误的，如果你不打算让软件架构师为成功交付做出自己的贡献，为什么还要让他们为软件设计投入全部精力？ 当然，有些情况下要参与到代码级别并不实际。例如，一个大型项目通常意味着要照看更大的“大局”，有可能你根本没时间写代码。但是一般来说，一个写代码的软件架构师会更有成效也更快乐。你不应该因为“我是架构师”，就把自己排除在编码之外。 6. 质量保证 即使有了世界上最好的架构，糟糕的交付也能让原本可以成功的软件项目失败。质量保证应该是软件架构角色的一部分，但它的内容不只是代码评审。你要保证一条基线，它可以是引入一些标准和工作实践，如编码标准、设计原则和工具。质量保证也包括确保团队对架构实现的一致。管它叫架构服从还是架构一致取决于你，但都要遵循技术愿景。 可以肯定地说，大多数项目没有做足够的质量保证，因此，你要弄清楚什么是重要的，并确保它有充分的保证。对我来说，只要是架构上显著的、业务上关键的、复杂的和高度可见的，都是一个项目的重要组成部分。你要务实地认识到没办法保证每件事。 合作或失败 一个软件系统很少孤立存在，可能有不少人要为整个架构过程作贡献。这包括了从需要理解和认同架构的直接开发团队，一直到那些对安全性、数据库、运营、维护或支持感兴趣的人组成的扩展团队。任何担任软件架构角色的人都需要与这些人合作，以确保架构能与周围环境成功整合。如果不合作，就等着失败吧。 技术领导是一个角色而非级别 软件架构的角色基本上就是向软件团队引入技术领导，有必要重申的是，我这里谈论的是一个角色，而非职务级别。通常，大型组织会作为对长期服务的奖励，或者因为想给某人加薪，而搬出“架构师”的头衔。如果接受这个头衔的人具备承担这个角色的能力，那就没问题，但情况并不总是如此。如果你订阅过LinkedIn或Stack Overflow的软件架构讨论组，可能见过类似的问题： 嘿，我刚晋升为软件架构师，但我不知道该干些什么。救救我！我要看什么书？ 尽管无法阻挡一些组织让人晋升到超出其能力的角色，我还是可以描述自己对软件架构角色的看法。设计软件可能是这个角色乐趣的一部分，但一个成功的软件项目远不止如此。 提出你自己对这个角色的定义 根据我的经验，尽管很多软件团队都明白自己需要软件架构这个角色，却往往没有一个参考定义。少了这个定义，很可能就无法履行这个角色的部分或全部职责。 大多数跟软件开发团队有关的角色都比较容易理解——开发人员、测试人员、流程经理、产品所有者、业务分析师、项目经理，等等。软件架构角色？不清楚。我经常问软件团队对软件架构角色有没有参考定义，常见的回答不外乎“没有”或“有，但我们不用”。同一个团队的人往往会给出不同答案。 软件架构的必要性通常是公认的，但这个角色的责任往往并不明确。根据我的经验，这可能导致没有人承担这个角色，或者有人被安排了这个角色，却不真正了解应该怎么做。如果没有理解角色，就不会发挥相应的作用，更遑论培养未来的软件架构师。 不管你怎么称呼它（比如架构师、技术主管、首席设计师等），我的建议都很简单。如果你没有什么东西可以用来表达“这就是我们对软件架构师的期望”，花些时间想想这回事。首先，对于对软件架构角色的期望，要跟你的团队达成共识；然后，如果看到益处，就在你的组织里对其标准化。