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

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

表现

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

架构

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

更大的价值

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

为架构而战

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