架构整洁之道二两个价值的故事

每个软件系统都提供两个价值给利益相关者：表现和结构。软件开发者应的确保这两个价值尽量高负责。然而很不幸，程序员很多只关心其中一个而忽略另一个，甚至更不幸，他们可能关注的不是这两个价值，留下没有价值的系统

表现

软件的第一个价值是他的表现，程序员被雇佣来帮利益相关者让服务器来挣钱或省钱，实现这个的方式是依照功能规范或写需求文档，来写代码实现这些需求。当程序出问题时，程序员修 bug。很多程序员相信这就是他们工作的全部，他们就是为了实现功能和修 bug 而工作，但这是错误的。

架构

第二个价值必须和软件这个词一起处理 – 一个由 soft 和 ware 组成的复合词。ware 意味着产品，soft 就是第二价值 –”架构“的所在的地方
软件具有柔软的特性，他打算用一种简单的方法改变机器的行为。为了达到目的，软件必须柔软，能够很轻松地改变，当利益相关者想要改一个需求，改变就需要简单并且可以轻松实现, 改需求的困难应该仅仅是改变的范围，不是改变的形态。
范围和形态都能驱动软件开发成本上升，但是两者是不同的。这就是成本不随需求改变的比例上升的原因，这也是开发一年比一年更便宜的原因。来自利益相关者的观点，开发者仅仅只提供了一些形态上的粗略改变，来自开发者的观点，老板的需求越来越难。
问题当然是系统的架构，架构不好，后面的需求将会越来越难适合现在的架构

更大的价值

功能或架构，谁能提供更大的价值，谁在软件开发中更重要，或者谁在添加需求中更能轻松修改系统。如果你问业务经理，他们可能觉得功能更重要，轮流问开发者，很多人也赞同这观点，但是这是错误的，我能用一个极端的逻辑工具测试他是错的。
如果你给我一个能运行，但不可能改变的系统，改需求就不能运行，这个系统将无用。
如果给我一个不能运行，但能够轻松修改的系统，我可以让他适应需求，然后运行起来。这个系统就有用了
你可能觉得这个例子不能让人信服，毕竟没有不能改变的项目，然而有些系统基本不可能改变，因为改变的成本超过了改变的好处。

为架构而战

为了实现架构这一责任，我们需要加入战斗, 我也许该用奋斗这个词。坦白地说，基本上都是这样说的。开发团队必须为能让公司发展最好的东西而奋斗。管理团队，市场团队，销售团队，运维团队也是如此。都要奋斗。
有效率的开发团队迎面奋斗。记住，作为一个开发者，你就是利益相关者，你需要维护的软件里有你的利益。这是你任务的一部分，责任的一部分，也是为什么你被雇佣的主要原因
如果你是架构师，这个挑战将会是双倍难度。架构的主要责任是系统的结构，，而不是开发功能，架构师创造一个允许快速开发，修改，扩展功能的架构。
记住，如果架构来晚了，系统将变得更难维护，修改对于部分或者整个系统最终将变得不可能。如果上述情况发生，那说明软件开发团队没有为必要的东西付出足够的努力。