《Fundamantals of Software Architecture》 Q&A Part3

第三部分 技巧与软技能

第十九章 架构决策

1.什么是掩盖资产反模式？
尝试做出架构决策时会出现的第一个反模式是掩盖你的资产。当架构师由于担心你做出错误选择而避免或推迟做出架构决策时，就会出现这种反模式。
2.有哪些技术可以避免电子邮件驱动的架构反模式？
仅在电子邮件正文中提及决策的性质和上下文，并提供架构决策和相应详细信息的单个系统记录链接。
3.Michael Nygard定义的识别具有重要架构意义的事物的5个因素是什么?
会影响结构、非功能特性、依赖项、接口或构建技术的决策。
4.架构决策记录的5个基本部分是什么？
标题、状态、背景、决策和后果。
5.在ADR的哪个部分，你通常会添加架构决策的理由？
背景
6.假设你不需要一个单独的替代部分，你会在ADR的哪个部分列出你建议的解决方案的替代方案？
状态
7.你将ADR的状态标记为Proposed的三个基本标准是什么？
成本、跨团队影响、安全性

第二十章 分析架构风险

1.风险评估矩阵的两个维度是什么？
风险的整体影响和该风险发生的可能性。
2.在风险评估中有哪些方法可以显示特定风险的方向？你能想到其他方法来表明风险时变好了还是变化了吗?
一般会在风险等级旁边标注通用的方向符号：＋或-号，来指示方向。
利用箭头及其趋向的风险评估数字。
3.为什么有必要将风险风暴作为一种协作活动？
没有架构师可以单枪匹马确定系统的整体风险。原因有两个。首先，单个架构师可能会错过或忽略某个风险域，此外，很少有架构师对系统的每个部分都有全面的了解。这就是风险风暴可以发挥作用的地方。
4.为什么风险风暴中的识别活动必须是一个单独的活动，而不是一个协作的活动？
这样可以使参与者将注意力集中在特定的维度上，避免因同一架构区域识别出多个风险而产生困惑。
5.如果三个参与者认为架构的某个特定区域的风险很高，而另一个参与者认为风险只是中等，你会怎么做？
询问为什么他认为是高风险，如果说服了认为中风险的参与者则将风险提高到高，或者认为中风险的没有被说服，因此，风险风暴需要合作。
6.对于未经证实或未知的技术，你会给出什么样的风险等级？
最高风险等级。

第二十一章 架构绘图和演示

1.什么非理性的工作附件，为什么它在编写架构文档和绘制架构图方面很重要？
早期创建临时性的设计图，可以防止架构师对自己创建的东西有过多的依恋，这是一种名为非理性的工作附件。
2.C4建模技术中的4C指的是什么？
上下文（Context)：表示系统的整个上下文，包括用户的角色和外部依赖。
容器（Container):架构中的物理（通常也是逻辑）部署边界和容器。这个试图为运维和架构师之间的沟通提供了很好的契合点。
组件（Component):系统的组件图。这个视图与架构师对系统的看法最为吻合。
类(Class)：C4类图使用与UML类图相同的样式，UML类图是有效的，因此不需要被替换。
3.在绘制架构图时，组件之间的虚线是什么意思？
异步通信。
4.什么是满是子弹的尸体反模式？在创建演示文稿时如何避免这种反模式？
这里面每张幻灯片本质上都是演讲者的笔记，只是所有人都看得到。演示者的幻灯片中全是文字，观众被迫阅读上面的所有内容，然后花十分钟事件等待演示者慢慢将要点信息一条条读完。
增量式地构建幻灯片，一点点构建(希望是图形化的方式)信息，而不是一次给出全部内容。
5.在做演示时，演示者的两个主要信息渠道是什么？
语言和视觉。

第二十二章 打造高效团队

1.架构师个性的三种类型是什么？每种个性创造了什么样的边界？
控制狂：产生紧密边界，会引起挫败感。
空想架构师：松散的边界，会带来混乱。
2.决定你在团队中应该表现出的控制水平的5个因素是什么？
团队熟悉度、团队规模、总体经验、项目复杂度、项目持续时间
3.你可以通过哪三个警告信号来判断你的团队是否过于庞大？
过程损失、多元无知、责任扩散
4.列出三个对开发团队有好处的基本清单。
开发人员代码完成检查清单、单元和功能测试检查清单以及软件发布检查清单。

第二十三章 谈判和领导能力

1.为什么协商对架构师如此重要？
通过与开发团队协作，架构师才能获得团队的尊重并形成更好的解决方案。
2.当业务利益相关者坚持要有5个9，但实际上只需要3个9时，说出一些协商技巧。
把事情分为几小时，几分钟。确认利益相关者的关注点，然后将谈判从9术语转换成合理的非计划停机时间。3个9平均每天有86秒的的非计划停机时间，这是一个合理的数字。
3.你能从一个告诉你“我昨天就需要它”的业务利益相关者那里得到什么？
上市时间对于利益相关者是很重要的。
4.为什么重要的是把关于时间和成本的讨论留到谈判的最后?
金钱和时间时任何谈判的关键因素，但应该作为最后的手段，以便首先尝试其他更重要和合理的理由。
5.分治法则是什么？当与业务利益相关者协商架构特征时，应该如何应用它？提供一个例子。
分治法则时分而治之，当与业务利益相关者协商架构特征时，将需求限定到到系统的特定范围，从而减少困难(且昂贵)需求的范围以及谈判的范围。
6.列出架构的4C。
沟通、协作、清晰和简洁。
7.解释为什么架构师既要务实又要有远见？
虽然架构师需要有远见卓识，但也需要应用实际可行的解决方案。
8.管理和减少被邀请参加的会议的技巧有哪些？
提前询问会议议程，以确定是否真的需要参加会议。

第二十四章 打造职业发展途径

1.20分钟规则是什么？什么时候使用它最好？
每天至少花20分钟来学习新知识或深入研究某个特定主题，从而为你的架构师职业生涯做出贡献。
早上第一件事。
2.在ThoughtWorks技术雷达上的四个环是什么？它们是什么意思？如何将它们应用到你的雷达上？
暂缓：“不要使用这项技术开始做任何新的事情”。在现有项目中使用它没有害处，但是开发人员在新开发项目中使用它时应该三思。
评估：表明一项技术值得探索，其目标是了解它将如何影响组织。
试验：试验环是为了那些值得追求的技术。
采纳：ThoughtWork强烈建议业界应该采用采纳环中的技术。
3。描述应用于软件架构师的知识深度和广度之间的差异。架构师应该追求哪一个最大化？
广度。