本文共 3105 字，大约阅读时间需要 10 分钟。
1.架构师为什么需要管理实践
答：在实践过程中，软件架构师主要障碍往往在于组织方面。
2.VRAPS组织管理原则有哪些
答：构想原则，说明如何向架构的受益人描述一幅一致的、有约束力和灵活性的未来图景；节奏原则，刻画一种在整个组织范围内协调程度，即定期地根据可预测的速度、内容、质量对制品生产进行检查和规划；预见原则，要在预测未来与检查并适应现状之间做平衡；协作原则，解决如何识别对架构成功关键的团体，以及如何确保这些合作伙伴的有效支持；简化原则，要求理解组织的结构，了解架构最小的基本特征并最小化架构。
3.VRAPS概念框架的基本概念
答：准则是把广泛的原则翻译成是否和如何执行原则的细节。每一项原则都附有一组模式，模式描述开发或者使用软件架构时可能遇到的常见问题解决方法。模式更注重于解决特定情况下的问题，传达在给定背景和多方竞争因素下针对常见问题的解决方案。返末世描述组织在实践中可能遇到的陷阱，描述了不该做的事情或者用在错误背景下的解决方案，可以帮助理解原则。
4.构想原则如何形成统一并应用到实践中
答：构想描述了架构的未来，提供了框架使用的环境和动机。构想是未来价值到框架约束的映射，必须把它所能提供的价值与客户的约束向对应。构想需要维持一致性和协调性，一致性是受益人各种期望之间的妥协以及它们与现在和未来的架构之间需求满足程度，灵活性是受益人在不破坏架构的情况下，基于现有架构完成事先没有预料到的需求难易程度。
形成架构构想的三步方法：清楚明确地阐述一条迫切的客户价值；将客户价值映射为少数特定的能解决的问题；将以上问题转译成一组特定的约束条件。
验证构想原则是否生效的标准如下所示：架构师的构想与发起人、用户、最终客户期望实现的目标是否保持一致；实施人员是否信任并使用框架；关于架构和构件的潜藏知识对其用户是否是可见的、可以获得的。
在构想中存在着反模式：风险置后，因临时要求变动原先的设计构件引入新功能，后患不断；墙头草，因没有良好构想，迫于压力不断更改架构，导致架构不稳定，接着引起人心不稳；一叶障目，具体开发人员只专注于自己部分的任务，不了解其他部分，最终导致临时解决方案堆积架构难以承受。解决这些构想中的反模式可以使用以下对应的方法：前后一致，积极维护构想，防止因短期压力变动，具体变动内容应仔细核实确认后才可以变动构想；三个臭皮匠，架构设计不仅只是需要架构师，还需要同客户一起协商沟通，同时不能将问题扩大化要针对业务问题；轮流工作，推荐开发人员之间资源知识共享，让开发人员接触并熟悉架构的其他部分，定期挪动其工作范围。
5.节奏原则是什么，怎么应用到实践中的
答：节奏是一个框架团体内部及它与客户和供应者之间反复出现的、可预测的工件交换活动。节奏有三个要素：速度、内容、质量。速度是一个团队与另一个团队之间同类型交接的频率。内容是指一个团队向另一个团队提供的价值。质量的含义是遵循开发过程确保架构没有缺陷。
节奏准则生效的体现有三个特征：经理们定期地再评估、同步和调整架构；架构用户对架构发布的进度和内容具有高度的信心；通过节奏协调可明确活动。第一个特征的反模式是一部成功，一旦项目复杂程度或者超过掌控者的能力，失败是不可避免的；正确的方式是采用定期评审发布，每一次发布做一次迭代。第二个特征的反模式是超敏捷，通过降低质量减少内容抄近路等方法维持稳定发布节奏；正确的做法是舍兵保帅，将不确定以及不重要的特性移动到下一个发布周期，保证发布质量稳定团队信心。第三个特征的反模式是销售未检验的产品，包括长时间不进行维护更新；正确的做法是产品要定期的运行一次，以防止运行环境或者其他更新的信息未支持同步，每次发布的产品都应该同步发布。
6.基于良好的节奏，应该怎么预测、验证和调整
答：预见是建立和实现架构的人员根据变化的技术、竞争和客户需求预测、验证和调整架构的程度。验证不仅局限于传统软件工程的测试和检查技术，也包括对架构基础假定的预测。软件架构的长期成功依赖于对假定变更和通过预测及验证获取信息的适应程度。调整是对架构计划及架构本身修正以加入新的特性，适应新环境和新市场。
预见原则生效时的特征如下所示：不断增强架构的响应能力，预见到风险、架构客户、客户需求，市场驱动的标准和演变技术，战略性业务方向的改变；通过快速复审和开发周期，评估技术和业务上的风险与机会；当认识到关键的评估或假设有错时，及时调整功能特性和预算。
预见原则的模式是示范区、架构复审、外包，对应的反模式有遗漏细节、品尝未熟的果实、创造奇迹。遗漏细节是提供架构的新功能时未考虑到一些关键的基础细节，导致存在功能缺陷；品尝未熟的果实是将不成熟或者是试验阶段的架构应用到商用或者生产场景，导致新架构质量不能承担使用场景的需要；创造奇迹是在有足够证据显示基础假设和估计已经完全偏离目标是，对架构开发和实现计划不做任何修改将发生的情况，这不是奇迹，是空想造物脱离实际需要。
7.协作原则是什么，怎么进行应用
答：协作原则解决了如何识别对架构成功起关键作用的团队，以及如何确保这些合作换班的支持等问题。协作是指架构受益人保持明确的、合作的角色并将其提供和获得价值的最大化程度。合作是受益人彼此之间存在一些共享的预期，应明确表示出达到或未达到预期会有哪些奖励和惩罚。
协作原则生效的特征有：架构师不断努力了解谁是最关键的受益人，他们如何贡献价值以及他们需要什么；受益人之间达成明确和强制性契约；通过社会行为制度和非正式规范强化合作。
协作原则的模式是了解你的受益人、互惠互利、杜绝意外、和HR密切合作，与之对应的反模式有光说不做、不记录讨论结果、非正式时间做正式工作。光说不做是需要架构是知道用户需求却没有将这些信息清晰的转接给相关的协作人员，或者协作人员和架构师知道而用户不清楚；不记录讨论结果，没有办法将讨论的关键点集中在有效范围内或者转换话题到指定的讨论点上；非正式时间做正式工作，最终导致工作内容无法把控，存在质量隐患。
8.简化原则是什么，怎么进行应用
答：简化原则要求对价值非常坚定和专注，以及对架构所生存的组织的理解和支持，为了实践这个原则，架构师必须了解架构最小的基本特征，并将这些特征传达给实现架构团队的每一位成员。简化是指做作用的组织和环境都进行巧妙地理解和最小化，组织形成架构并思考架构。在简化架构之前必须澄清组织和架构。
简化原则生效的特征有：开发人员长期使用架构，减少了总成本和复杂性；架构小组明确理解关键最小需求，并且将其构造成多应用共享单车额核心元素；通过长期的预算和行动确保相关元素没有被共享、增减不必要的复杂性时或者有明确业务理由时，可把相关元素从核心移走。
简化原则的模式有由慢而快、迁移途径、统计构件变更，与之对应的反模式有简单复制并修改、缺乏有效抽象、编码大于架构。简答复制并修改描述了当程序员学会使用或重视架构之前被强迫迅速完成任务时发生的情况，容易引入重复性代码和冗余实现，当然bug也不例外；缺乏有效抽象在于前期还算简洁，后期引用规模扩大会导致单点解决方案强制性糅合，缺乏足够的共享性导致应用的平台越来越大但是运行效率越来越低；编码大于架构主要是防止架构师成为架构的实现者，在这种情况下，架构师的职责无人承担，最终架构崩盘。
转载地址：http://jmpdi.baihongyu.com/