敏捷软件架构

许多组织都倾向于采用敏捷形式的项目管理。这给架构师的角色带来了新的担忧；事实上，有些人认为敏捷和架构是冲突的。敏捷宣言的两位原始签名者 Martin Fowler 和 Robert Cecil Martin 一直强烈反对这种观点。事实上，Fowler 清楚地阐明了一个事实，即虽然敏捷宣言对大型前期设计（如 Prince2 中的那种）持敌视态度，但敏捷并不拒绝前期设计本身。

计算机科学家艾伦-霍鲁布（Allen Holub）也有类似的观点。敏捷注重的是，要交付对用户有用的软件，而不是对销售人员有用的软件。为了使软件长期有用，它必须具有适应性、可扩展性和可维护性。

Fowler 还对软件开发团队中的架构师提出了愿景。他指出，不可逆转的软件很可能在日后最令人头疼，而这正是架构决策的关键所在。在此之上，他认为架构师的职责应该是设法使这些决策具有可逆性，从而彻底消除问题。

在许多大规模的软件部署过程中，都可能会用到 "我们已经到了不归点" 这句话。在不归点之后，将部署恢复到初始状态就变得不可行了。软件也有自己的 "不归点"，即重写软件比重建软件更难。虽然软件可能不会达到这种不归点的最坏情况，但可维护性难度的攀升会给业务带来困难。

Fowler 还指出，在很多情况下，软件架构师甚至不会检查软件是否符合其原始设计。通过与架构师结对编程，以及架构师审核代码变更（即拉取请求），他们可以获得理解，从而向开发人员提供反馈，并减少进一步的技术债务。

在本书中，你可能会注意到 UML 的缺失；这是因为在我看来 UML 并无必要。我的意思是，我们都是在使用 PHP，对吗？不过，你可能会发现 UML 对你的团队很有用。

架构过程通常会产生一个可交付成果；我们称这个可交付成果为工件（artifact）。在敏捷团队中，这些工件可能是以演进的方式开发出来的，而不是一个前期产品，但尽管如此，在敏捷环境中进行架构设计是完全可能的。

事实上，我认为架构可以让敏捷环境下的工作变得更加容易。当按照接口或抽象层编程时，替换类要容易得多；而在敏捷环境中，需求可能会发生变化，这意味着可能需要替换一个类。软件只有在对最终客户有用时才是有用的。敏捷可以帮助实现这一点，但为了实现敏捷，你的代码必须具有适应性。拥有优秀的架构对实现这一目标至关重要。

当我们编写代码时，我们应该编写防御性代码。然而，对手不是敌人，而是我们自己。降低可靠代码的最快方法之一就是将其编辑为弱代码。