“融化奶酪效应”的处理

核心提示： 我们需要解决客户端和服务端双方面的代码改变问题，在这个系列文章中，“融化奶酪效应”的处理(6)，我们将探讨一些有可能最大限度减少变更代码量和分散度的方法，但是，这些实例可能会使得将来的变动更加困难和昂贵，它们将解决方案设计成非开放式的，这些也只是我们面临的一部分挑战而以，应用这些变化会带来

我们需要解决客户端和服务端双方面的代码改变问题。在这个系列文章中，我们将探讨一些有可能最大限度减少变更代码量和分散度的方法，但是，这些也只是我们面临的一部分挑战而以。应用这些变化会带来很多挑战。改变的代码需要被重新测试，更重要的是，改变的配置也要重新测试。

安装也是一个问题，在服务端着方面，可能还不是一个大问题。但是，客户们经常是分散在很多不同的设备上的，它们可能在线也可能不在线，或者更糟的，它们可能超出了组织的范围，但他们同样需要被更新。应用点击和应用更新块的策略帮助客户检查是否需要更新然后安装上新代码，这些允许我们可以集中的发布代码。但是，发布代码只是需要做的事情的一部分。配置也需要被改变，如果结构发生了改变，那么解决方案还需要清空缓存，更糟的，也许我们还需要更新各种数据库。虽然更新应用块在客户端提供了这个接口，它的具体实现还需要被完成。

底层设施也会变化。新的授权机制，新的防火墙，更新、更可靠或者更快的底层设施有可能出现，或者为之发生改变。合并和增加会对底层设施造成影响，而且大都是使之变得更加多样化和复杂。这样的变化也会对软件设施造成影响。通常，变化的功能对底层设施和软件设施都会造成影响。

任何功能上的更新和变化都会引起运动机件之间互动的变化。结构会变，接口会变，合同会变，自然，使用它们的过程也会变。

随着硬件的更新以及新需求的提出，可能是业务需求或者是操作需求比如说安全，操作环境也会变化。解决方案必须也支持这种变化。为了实现这种改变，解决方案与操作环境之间必须是一种松耦合的关系。现在，操作需要一般都会被整合到方案设计中，作为它的一部分。比如说，当授权是解决方案至关重要的一方面时，隐秘的授权机制方面的知识就被应用在应用内部去完成授权。开发者也会显示或隐式的使用其他方面以及操作环境方面的知识来建构解决方案。这些实例可能会使得将来的变动更加困难和昂贵。它们将解决方案设计成非开放式的，使它与操作环境之间形成了一种紧耦合的关系。