Daniel-Journey Weekly Dose-2010/5/29
Design Pattern
Architecture
“更好的定义是：‘在大多数成功的软件项目中，从事该项目的专家开发人员对设计系统的设计存在共识。这种共识被称为 “架构”。这种共识包括如何将系统分为组件以及组件如何通过接口进行交互。’”
有三个问题可能会产生偶发复杂度。我已经讨论了第一个：由于日程或其他外部压力而导致临时大量削减代码。第二个是复制，The Pragmatic Programmers 中称其为对 DRY（不要重复自己，Don’t Repeat Yourself）原则的违背。复制是软件开发中最能让人在不知不觉中降低软件质量的因素，因为在开发人员甚至还没有觉察的情况下，它会蔓延到许多位置。一个明显的例子是复制并粘贴代码，但是也存在大量更复杂的示例。
偶发复杂度的第三个诱因是不可逆性。您做出的无法逆转的所有决定都将最终导致某种程度的偶发复杂度。不可逆性将同时影响架构和设计，尽管它的影响在架构级别上比较常见并且比较有破坏性。尽量避免作出不可逆转或者难于逆转的决定。我的一些同事信奉在最后责任一刻 做决定。这并不表示您应当把决定推迟得太久，只要推迟得比较久就足够了。什么时候才是决定某些架构关注点的最后责任时刻？做决定的时间拖得越晚，您为自己留下的可能性就越多。问问您自己：“我是不是现在就需要做那个决定？” 以及 “我做什么能让我推迟那个决定？” 如果在决策过程中应用一些技巧，那么您将会对您可以推迟的内容感到十分惊讶
Big Design Up Front 设计方法学的支持者在开始编写代码前，要花费大量的时间确定当前应用程序的所有必需的设计元素。编制的文档中的大多数内容对于解决方案的总体设计仍是重要的。但是，在实现软件的过程中，会不断遇见意外。实现的每个设计元素与其他设计元素相互联系，形成极端复杂的依赖和关系网络。代码中有些方面本以为平常不过，但是一旦要实现系统中其他所有必需的部分时，复杂度又随之放大。由于不能理解代码中不同设计元素之间复杂的相互作用，导致在估算完成解决方案所需的努力时困难重重。在软件方面，估算仍是一种玄妙的 “黑色艺术”，因为对于如此复杂的耦合和交互网络，实在是难以理解，因而也难以分析。
依赖于紧急设计的敏捷方法学则尝试一种不同的方法。敏捷架构和设计在编写代码前也不会避开设计，但是它们的实际工作者已经知道，只有等到实现了重要的部分后，才能彻底地理解整个问题。紧急设计中的开发技巧使您可以推迟做决定，直到掌握了更多的上下文。精益软件运动（见 参考资料）有一个很好的概念叫做 最后可靠时刻（last responsible moment）：不是将决定推迟到最后时刻，而是最后可靠时刻。越是往后推迟设计决定，就能掌握越多的信息，从而可以做出更精妙、更符合实际的决定。
Webwork是一个优越的框架，它的设计基于这样一个基本原理：完成通用任务应该是简单的，而构建高级的设计也应该是可行的。
Webwork是一个MVC框架，但同时它也是一个轻量级容器。
在Rickard Oberg（Webwork的创作者和JBoss创始人之一）构建最初版本Webwork的时候，他曾说过“框架的强大之处不是源于它能让你干什么，而是它不能让你做什么”。Rickard说过的话解释了什么是框架：框架使混乱的东西变得结构化。
我们再来一个比方。框架就像是一间有很多房梁的房子，当你需要扩建房子的时候，譬如增加新的房间、窗户、或者卧室增加一个壁炉，由于房梁的限制，你并没有其他的选择。虽然，较少的屋梁和架构会让你有更多的选择，但是当台风来袭或者发生地震的时候，你让你的家人住在一间只有屋顶的房子里，恐怕也不会觉得安全吧。
由于框架会要求更多的结构，你的创造力所拥有的发挥空间开始收缩了。一种极端的情况就是框架消失了，一片混乱；而另一种极端就是框架留给你的选择是如此之少，以至于你无法完成你的应用程序。很明显，一种完美的中间状态存在于这个极端之间的某一处，而这种中间状态就是Webwork和所有其他MVC框架所梦寐以求的。
很多人认为从需求分析到架构设计之间的过渡遇到很多问题，究其根源，可能是以下的原因造成的：
- 用例是面向问题领域的，而设计是面向机器域的，这两个‘空间’存在映射。
- 用例技术本身不是面向对象的，而设计应该是面向对象的，这是两种不同的思维方式。
- 用例规约采取自然语言描述，而设计采取形式化的模型描述，描述的方式不一样。
博主够犀利！欢迎回访！