基于模式的架构评审(3)

　　参与者对于评审本身及其结果都非常的积极与确信，个别人显示出极大的热情。他们的反馈展示了来自评审的四大好处：
　　基本质量属性问题。PBAR差不多可以平均在每个项目中找出四个问题，其中包括一个重大问题。在一个案例中，架构使用了分层模式，但是需要提升性能，可选的一种方案是规避分层——一条独立的贯穿系统的路径。在另一个案例中，评审暴露出用户接口的设计(基于已存在的软件)相当晦涩，以至于很难扩展。
　　团队对架构的理解。有这样两种说法，“评审帮助每个人看到了全景图”，并且，“评审有助于澄清和统一系统的愿景”
　　团队对质量属性需求的理解。举个例子，团队知道系统是可靠的，但是需要更深入的说明。在评审中，我们会决定系统并不需要连续不间断的运行，但是它必须能够处理某些错误的情况。
　　团队成员需要深入了解软件架构本身。经过PBAR过程，团队了解了架构模式以及它们与质量属性之间的关系。
　　很明显，我们需要在这些利益与成本之间进行权衡，幸运的是，成本相当低廉——总共需要所有参与者耗费的精力不会超过两个工作日。简短的准备时间可以让团队很好的利用评审来应对需求变更。虽然从来没有哪场评审是我们特别为应对需求变更而举办，但在某些情况下，会对它们在很短的时间内进行规划(一周甚至更少)。我们唯一听到的真正的抱怨是关于评审的时间点——大多数都是在开发进行的差不多了才进行评审，个别参与者希望评审可以更早的进行。
　　如果参与者发现评审的有用之处，并能对那些列举的问题起到作用，我们就成功了。对于9个案例中的6个而言，已被证实是对的。而导致那三个失败案例的可能因素有以下几点：
　　那些列举出的问题都已经发生并产生了负面作用。
　　我们并没有收到评审结果的确认，可能是因为评审是离线(offline)进行的。
　　评审没有进行完，主要是因为评审者是一名架构新手。(在一个特别的案例中，连需求都还没有与用户确定，在这种情况下，也就无法在违反需求的情况下对架构进行评审)
　　从失败的评审我们获得了不少教训，评审必须全员参与并且在开发周期的早期完成，但是也不要过早的在需求都尚未被理解的情况下进行。最后，需要一位擅长架构和架构模式的人来引导大家进行。
　　详细的实例
　　为了说明PBAR过程和它的带来的好处，我们选取一次评审并对它进行详尽的描述。我们将要学习的项目是一个学生课程项目，而学生是没有时间去做冗长的项目评审的。只有三个开发人员的小团队并没有遵循什么方法论，他们只编写了少量的需求，并且没有架构文档。另一项挑战是，该项目开发的是一个安卓应用，而安卓的软件开发套件在当时非常新，并且在不断的变化中;这也影响了应用的开发和实现。
　　我们从讨论功能和质量属性需求开始进行评审。我们讨论了各种场景，帮助我们理解最重要的四个质量属性：易用性、安全性、可靠性(故障容错)和可扩展性。这对发现故障及容错尤其有帮助。然后我们讨论架构并将它画在白板上，利用方框和连线分别表示组件和连接器。其中一位团队成员做好笔记，这样一来，在评审结束后团队将会得到一些架构文档。我们列举了两种架构模式：点对点和共享资源库。[20]
　　我们列举了质量属性的三个问题，其中之一非常重要，然后我们讨论解决这些问题的方法，并总结了三种团队可以实现的措施去解决这些问题。伦恩•贝思(Len Bass)和他的同事则称之为策略。[21]我们在架构图表中进行标注哪些部分可以实施策略，这样可以给团队如何去实现这些策略的概览图。评审总共进行了不到两个小时。
　　团队记录了以下几点由评审带来的特别帮助：
　　产出了一些架构文档;
　　提高了大家对架构的理解;
　　提高了大家对项目质量属性需求的理解;
　　列举出一些问题及初步的解决方案。
　　以上经验证明，PBAR在即使完全没有架构文档和只有很少的需求文档时也非常有用。
　　通过这些使用PBAR的经验，我们学习了一些如何让PBAR更加成功的重要且全面的经验。架构评审者必须来自项目之外，这是所有类型的评审都适用的一种情况，并且与结对编程具有相似的原理——从另一个视角来发现项目成员无法发现的问题。如果团队中有两位评审者会具有更好的效果。
　　此外，评审应该在架构已足够完备并产生评审意义后尽可能早的完成。非常重要的一点是，需要注意到PBAR本身的轻量级特性，这使得它应该尽早实施，甚至是在架构确定之前。然而，如果质量属性需求尚未确定的话，评审很可能会失败。
　　假使架构师并没有在他们的架构中显式使用模式，那又会怎样呢?这是我们指导过的大多数评审中出现过的情况。但是因为架构模式通常总是存在的，[22]评审可以正常地进行，而模式自然而然就会被识别出来。
　　遗憾的是，PBAR不能找出一些传统架构评审才能找到的问题。取而代之的是，它提供了一种取舍：一种只需要很少时间和精力，并且可以工作在只有少量架构文档的情况下，当然尤其是在无法使用重量级评审过程的敏捷项目中使用的评审过程。PBAR可以发现在已使用的架构模式和重要质量属性的不协调情况(例如，性能对应分层，又或者是容错对应管道和过滤器);但它无法发现类似由复杂的交互组件产生的性能缺陷等问题。
　　另一个限制是评审者们必须非常的精通架构，架构模式，质量属性以及策略。这与传统的评审很类似：评审者需要具备类似的专业知识，虽然架构模式知识并不是决定性的。关键的挑战是很多地组织需要物色到具有充分专业性的评审者。
　　差不多到目前为止所有使用了PBAR的项目都非常小，也许并不能很好解决像工业级别项目的大规模的需求。虽然用户会认为这方面经验的不足是一个限制，但是我们依然希望PBAR会继续更加成功地发展。

原文转自：http://www.ltesting.net