实现并验证架构

不值得验证的架构不值得设计。

 

如果我们决定接受第一颗子弹，那么子弹到来的越早、越快对我们越有利。

 

原型技术的思想：对感兴趣的问题先试试看，而故意忽略其他方面的要求，从而使‘试试看’的成本远远低于‘正式干’的成本。

 

根据实验或者评估的结果，我们可以做出很多有意义的判断：

1.       我们担心的风险是否真的存在

2.       通过开发原型是否找到了风险的解决方法

3.       下一步，我们是让项目继续还是将项目取消

4.       如果是悬而未决，我们是否需要继续开发原型还是去探寻问题解决的方案。

 

根据不同的分类原则，可以将原型分为不同的类型：

根据开发原型的目的是模拟系统运行时的概貌、还是纵深的验证一个具体的技术问题，可以将原型分为水平原型和垂直原型。水平原型在一定程度上实现了用户交互层的界面布局和界面跳转逻辑，垂直原型就像一个‘垂直切片’，它往往是涉及到不同的层，将为数不多的功能真正实现。

根据开发的原型是否被抛弃，我们可以将原型分为抛弃原型和演进原型。

 

由于两种分类的原则是独立的，所以可以综合两种分类原则，将原型分为4类：水平抛弃型、水平演进型、垂直抛弃型、垂直演进型。

 

水平抛弃型很常见，我们常用的静态页面模型就属于这一类，它非常强调‘通过故意忽略其他方面的要求来降低原型开发的成本’，大多数用来需求启发的水平抛弃原型只注重模拟待开发系统的界面布局和界面流转情况，真正的业务逻辑都没有实现，也没有任何数据库连接生效。

 

水平演进原型很少，一般都是和特定的RAD环境相关，例如当我们采用VB开发时，就可以这样做，而且，引领Web界面开发的面向对象潮流的JSF、Tapestry框架的出现，也起到了推动的作用。

 

垂直抛弃原型一般用来进行技术验证，在很多项目中，常会碰到一些不熟悉的技术点，如果这些技术点对项目的成功影响很大，那么就应该通过开发垂直抛弃原型的方法，先看一下它是否真正能够解决问题。

 

垂直演进原型和迭代式软件开发所暗示的‘多次交付，增量交付’的思想完全一致。它强调逐步提供用户所要求的功能，在实践中，我们应该注意每个此次将提交的功能必须是可用的而且具有或接近产品发布级的品质，而不是有些实践者认为的无需达到发布级质量。

 

水平原型又称为行为原型；垂直原型又称为结构原型；抛弃原型又称为探索原型。

 

验证架构的两种方法：原型法和框架法。对于项目型开发，一般采用原型法，尤其是垂直演进原型；对于产品型开发，采取框架的方式更有优势，所谓‘架构验证的框架’就是将架构设计方案用框架的形式实现，并在此基础上进行评估验证。

 

参考文献：

《软件架构设计》  温昱

 

 

PS：

还记得高中的时候，一位对我影响很深的老师对我说‘不要以为你知道这个知识点就可以了，大家基本上都知道所有的知识点，但是为什么到了考试的时候有的分数高，有的分数低呢，关键是你对各个知识点是否都融会贯通了，要形成一个完整的知识树，这样不论遇到什么类型的题目，都能得心应手’。做软件开发也有一段时间了，遇到的问题也挺多的，总是见招拆招，一直没有形成一个完整的体系。

经过一个多月的时间，终于把《软件架构设计》从头到尾看了一遍，有些章节是看了很多遍，这本书写的很不错，在很多地方，看完后觉得软件开发就应该是这个样子的，于我心有戚戚焉。