知识卡片

架构知识的腐蚀风险与修改隔离区域机制

普通读书笔记卡

内容

架构知识按Lago等人的定义等于”架构设计+架构设计决策”——不仅要有解决方案本身,还要说明”当初为什么采用这种架构”的设计依据。架构知识管理侧重于开发实现过程涉及的架构静态演化,从架构文档等信息来源中捕捉知识,为质量属性及其设计依据提供记录和评价,从而帮助未来的架构维护和演化。架构知识管理的价值在于:如果不对架构知识进行管理,关键的设计知识就会”沉没”在架构之中,一旦开发组人员发生变动,这些沉没的知识就会”腐蚀”——这个”沉没→腐蚀”的比喻精准刻画了架构知识流失的机制:知识不是突然消失的,而是先失去被主动维护和访问的通道(沉没),再随人员流动逐渐失真变质(腐蚀)。书中指出当前架构知识管理的现实困境:构建架构的利益相关者(真正拥有架构知识的人)通常不会主动用文档记录架构知识,原因包括文档化维护的短期收益看起来不够、成本相对较高;利益相关者对工程本身的短期兴趣压过了对长远知识重用的关注;开发者更容易被设计中的创造性工作吸引、而不愿反思设计决策的长远影响;缺乏相关培训。即便真的做了文档化,知识也常常无法在组织内充分分享——可能没有传播给合适的利益相关者,可能接收者没把知识用到自己的任务中,也可能是知识本身太”笨重”、难以在需要时被快速搜索定位。为了在修改架构时控制影响范围,架构修改管理的一个主要做法是建立”隔离区域”(region of quiescence)——保障该区域内的任何修改对其他部分的影响很小甚至没有影响,为此需要明确修改规则、修改类型以及可能的影响范围和副作用。架构版本管理则为演化的版本控制、使用和评价提供依据,为演化的量化度量奠定基础,例如用架构的邻接矩阵和可达矩阵对静态演化的波及效应做量化界定、计算组件在架构中的相对贡献大小。

参考来源

- 位置:《软件架构理论与实践》第9章《软件架构的演化和维护》"9.4.1 软件架构知识管理"及"9.4.2 软件架构修改管理"节(源文件:_epub-src/OEBPS/text00075.html) - 结论依据:原文说明"如果对架构知识不进行管理的话,那么关键的设计知识就会'沉没'在软件架构之中,如果开发组人员发生变动,那么'沉没'的架构知识就会'腐蚀'",并说明架构修改管理"一个主要的做法就是建立一个隔离区域(region of quiescence),保障该区域中任何修改对其他部分的影响比较小,甚至没有影响",直接支撑本卡片结论。 - 原始内容:许多人认为架构知识的可获得性能够极大地提升软件开发流程。如果对架构知识不进行管理的话,那么关键的设计知识就会"沉没"在软件架构之中,如果开发组人员发生变动,那么"沉没"的架构知识就会"腐蚀"。