敏捷宣言：软件架构师的视角（上）

大多数软件开发团队都了解敏捷宣言所描述的“内容”部分。但是，对于软件架构师来说，挑战在于“如何”变得敏捷，因为他们与开发人员实现相同目标的方式不同。除此之外，一些敏捷团队可能认为软件架构师角色是不必要的，模糊的，甚至违背敏捷软件开发的原则。

虽然一些敏捷框架试图为软件架构师的角色创建一个书面定义，但是这可能会导致一些人因为遵循指导，而没有达到他们应该达到的敏捷和实用的程度。一个好的架构师必须不断调整自己的行为，不要偏向某个特定的框架或方法，保持与流程的相关性，并为团队提供必要的指导和愿景。当确立了正确的心理模型时，敏捷宣言的价值将被自然地采用，这是所有敏捷软件开发方法的支柱。

敏捷价值：

在全面的文档之上使用软件

在过去，特别是在瀑布时代，像“宇航员架构师”和“象牙塔架构师”这样的术语被用来定义一个离地面团队太远的架构师。他们并没有为软件本身增加真正的价值，而是更专注于以图表和规范的形式创建全面的文档，而不是创建可工作的软件。不幸的是，尽管我们开发软件的方式发生了巨大变化，这种现象今天依然存在。

支持“工作软件”并不意味着必须忽略文档。这两个方面并不矛盾，也不应相互排斥;相反，它们必须在最终产品中包装在一起。软件架构师必须记住敏捷宣言的最后一句话:“虽然右边的项目有价值，但是我们更重视左边的项目。”

综合文档可能会成为陷阱

架构师仍然必须考虑全局，并继续维护系统的技术完整性，并注意集成点。在某些情况下，架构师应该进行前期分析来评估即将到来的业务规范，以便评估与当前架构相关的潜在风险，并使其对所有涉众透明。

当与新的外部系统集成时，或者对于具有体系结构影响的内部功能，这可能是至关重要的。在这两种情况下，如果架构师准备一些高级设计，就会变得事半功倍。一个粗略的组件图或一些功能用例可以作为进一步讨论的基础，并帮助团队全面理解所有涉及的组件。

然而，当涉及到具体的技术设计时，我的建议是让团队参与进来，集思广益，达成一致。这种协作在开发过程中既不应该太早也不应该太晚。例如，在常规sprint的情况下，架构师和团队可以在sprint开始之前的细化会议上达成共识。所有与该技术解决方案相关的实现细节(例如用于组件内部通信的内部API、多线程模型、数据库实体模型等)都可以在sprint开始时进一步讨论。

创建和更新技术文档必须在同一任务（在同一个sprint中）下进行，作为持续开发过程的一部分，并作为所有团队成员的共同责任。然而，架构师应监督并确保此流程顺利运行并成为团队文化的一部分。

当文件很重要时

为了实现和维护团队内部的良好协作，并不断地参与开发过程，架构师必须是敏捷团队的一部分。这意味着积极地编写和审查代码，处理新特性请求，并监督端到端交付过程。

与开发人员相比，架构师可能在编码活动上花费的时间较少，但是尽可能多地编写代码是极其重要的。例如，我平均花费至少30-40%的工作时间编写代码(有时甚至是一整天)，其余时间用于会议和其他技术活动(例如技术设计、评估未来的业务规范)。

开发任务的性质可能不同，架构师必须关注在应用程序的敏感部分或体系结构的关键部分编写代码。或者，根据团队环境的不同，他们可以像其他高级开发人员一样处理任何任务。

除了编码，架构师还必须积极地参与评审其他人的代码，这可以提高不同模块之间对代码库的认识和知识。一个主要的关注点必须是检查应用程序中对性能、安全性或其他质量属性至关重要的那部分的代码。体系结构代码评审还应该确保系统边界(例如API、通信类型、消息等)、体系结构核心原则和设计准则不被违反。这有助于架构师确保预想设计和实际实现之间的一致性和完整性。

要更好地理解真正的挑战，并提供有意义的技术解决方案，唯一的方法就是“不要插手”。编写和审查代码使架构师与开发人员更接近，从而更好地理解他们的实际问题和需求，并培养深入的产品知识。

（未完待续）

注：本文译自InfoQ

点击【在看】与好友一起分享

来源：hailang2ll