永远不要忽视你的项目架构

ThoughtWorks 的 Martin Fowler 在 OSCON 2015 第二天早晨以关于架构的演讲开始。

Fowler 在演讲开始时定义了软件架构的含义。《人们普遍接受的常见定义》是：“系统基本组织结构体现在其组件、组件彼此之间以及与环境的关系，以及指导其设计和演变的原则中。”

但 Fowler 说，真正重要的是，那些从事开源项目的人对系统是什么以及它如何工作有共同的理解。领导项目的专家之间这种共同的理解才是真正重要的。

还有另一种定义，即开发者应该尽早做出架构决策。Fowler 认为，架构实际上只是一系列难以更改的决策列表。例如，编程语言的选择是以后难以更改的，因此这是架构的一个组成部分，必须尽早决定。所有这些都归结为架构是关于“重要事情”的决策。

那么我们为什么要关心呢？

我们经常听到关于我们的开源项目的这个问题。人们会坚持认为“我们需要减少对质量的投入，以便我们可以为下一个版本构建更多功能。” Fowler 说，这种论点的问题在于，它假设“质量”是我们可以用来权衡成本的东西。但是谁来决定这个成本呢？

架构是软件的内部质量，并且对大多数用户来说是不可见的——那么他们为什么要为他们看不到的东西支付更多费用呢？因为随着时间的推移，添加和增强软件变得越来越困难，因为内部结构没有在早期考虑并且没有保持健康（从 Martin 那里了解更多关于这个假设的信息）。起初，低内部质量似乎是胜利，但高质量确保了从长远来看，我们可以更快地添加更多功能。

我认为我们所有人（房间里的人和阅读本文的参与开源社区的人）都在我们的项目中处理过这种类型的问题。我知道我在从事 Koha 时一直看到它。你什么时候花时间关注内部结构，你什么时候关注新功能——以及你如何取得平衡？

本文是 OSCON 2015 的 OSCON 系列文章的一部分。OSCON 涵盖了所有开源内容——完整的堆栈，包括您每天工作中使用的所有语言、工具、框架和最佳实践。OSCON 2015 将于 7 月 20 日至 24 日在俄勒冈州波特兰举行.