方法论层
GL-METHOD
层组基础进阶高级67 节点
§1组简介
组目录:本质层方法论层技术实践层域·概念与需求域·架构设计域·实现与构造域·测试域·部署域·运维域·演化与弃用域·质量属性域·团队与康威域·方法论主干域·跨域横切·质量属性横切·技术债横切·团队与康威案例层
本组 67 个节点,类型为 层组,域 O,覆盖阶段 基础 / 进阶 / 高级。
§2成员节点目录
| 节点 ID | 名称 | 层/来源 | 阶段 | 简介 |
|---|---|---|---|---|
| MTH-F-01 | 需求工程过程 | 方法论 methodology | 进阶 | 以业务或任务分析为起点,依次经干系人需要与需求定义、系统需求定义,并在各技术过程中嵌入需求活动,由需求管理贯穿的过程链;其信息项包括业务、干系人、系统与软件需求规格。 |
| MTH-F-02 | 需求获取 | 方法论 methodology | 基础 | 系统化地从干系人、领域文档、现有系统与运行环境等来源引出需要与需求的实践;目标不是记录已陈述的诉求,而是发现真实、隐含乃至尚未成形的需要。 |
| MTH-F-03 | 干系人识别与分析 | 方法论 methodology | 基础 | 系统识别受系统影响或能影响系统的个人与组织,分析其关注点、影响力与需要,并持续维护覆盖多层级角色的干系人视图的方法。 |
| MTH-F-04 | 需求规格说明 | 方法论 methodology | 进阶 | 把需求以明确、无歧义、可验证的方式文档化为信息项(如软件需求规格说明)的方法,要求单条需求具备必要、无歧义、单一、可行、可验证等特性,需求集具备一致、完整、可理解等特性。 |
| MTH-F-05 | 功能与非功能需求分类 | 方法论 methodology | 基础 | 把软件需求区分为功能需求(软件须执行的功能与行为)与非功能需求(功能之外的质量约束与属性),并另行识别技术约束与服务质量约束的分类方法。 |
| MTH-F-06 | 需求属性与优先级 | 方法论 methodology | 进阶 | 为每条需求赋予唯一标识、优先级、依据与假定难度等属性,并据此对需求排序与范围匹配,使有限的工程投入投向最高价值与最必要的需求。 |
| MTH-I-01 | 测试层次 | 方法论 methodology | 基础 | 测试层次是按开发生命周期阶段组织并一起管理的测试活动分组,通常从组件级逐层上升到系统级与验收级;每个层次针对不同的测试对象与关注点,回答不同的问题,并对应不同的缺陷类型与执行主体。 |
| MTH-I-02 | 测试类型 | 方法论 methodology | 基础 | 测试类型是与特定质量特性相关的一组测试活动,如功能测试与非功能测试,也可按是否依赖内部结构分为黑盒、白盒与经验型;大多数测试类型可应用于每一个测试层次,层次与类型是两个正交的坐标。 |
| MTH-I-03 | 测试驱动开发 | 方法论 methodology | 进阶 | 测试驱动开发(TDD)是先写测试、再写实现、随后重构的开发技术,核心为红-绿-重构三步循环:先写一个失败的测试明确目标,再以最小实现使其通过,最后在测试保护下改善结构。 |
| MTH-I-04 | 测试金字塔与反模式 | 方法论 methodology | 进阶 | 测试金字塔是按粒度与数量组织自动化测试的模型:底层应有多得多的快速隔离单元测试,中层为适量服务/集成测试,顶层为少量端到端测试;倒置的金字塔(冰淇淋甜筒)与缺失中间层的沙漏是典型反模式。 |
| MTH-I-05 | 测试替身与测试策略 | 方法论 methodology | 进阶 | 测试替身是在测试中替换生产对象的任何协作对象的泛称,包括哑元、伪造、桩、监视与模拟五类;按需要隔离的程度选择替身类型,并控制替身的使用范围,是平衡测试速度、确定性与保真度的关键策略。 |
| MTH-I-06 | 质量门控与持续集成 | 方法论 methodology | 进阶 | 持续集成要求开发者频繁把改动合并回主线,并由自动化构建与测试验证;质量门控则用一组在分析时度量的条件判定制品是否可发布,任一条件不满足即阻断构建或合并,把测试与质量检查制度化为交付闸门。 |
| MTH-I-07 | 软件测试过程模型 | 方法论 methodology | 高级 | 软件测试过程模型把测试描述为可治理、可管理、可实施的分层过程:组织级制定测试方针与策略,管理级规划、监控与收尾测试项目,动态级设计、实现、执行并报告具体测试,可配合不同开发生命周期使用。 |
| MTH-J-01 | 部署流水线 | 方法论 methodology | 基础 | 把从代码到生产的交付拆为多个自动阶段,每阶段提升置信度(通常以更多时间为代价),只构建一次并让同一制品逐环境提升,从而尽早检出会导致生产问题的变更。 |
| MTH-J-02 | 发布工程 | 方法论 methodology | 进阶 | 以可复现、自动化的方式构建并交付软件的工程学科,覆盖源码管理、编译、构建配置、包管理与安装,确保每次发布都可重复,而非一次性的独特雪花。 |
| MTH-J-03 | 封闭构建 | 方法论 methodology | 进阶 | 对构建机器已安装的库与软件不敏感、只依赖已知版本编译器与库的自足构建过程,使同一版本在不同机器上构建得到一致结果。 |
| MTH-J-04 | 配置外置与显式化 | 方法论 methodology | 基础 | 把随部署环境变化的一切(凭据、资源句柄、每次部署的取值)从代码中严格分离并显式声明,使同一不可变制品能通过注入不同配置部署到任意环境。 |
| MTH-J-05 | 渐进暴露部署策略 | 方法论 methodology | 进阶 | 把新版本分阶段、逐步暴露给更大范围的用户与基础设施,而非一次性全量切换;蓝绿以双环境切换、金丝雀以小比例扩量、滚动以实例渐替,均以健康判据驱动推进。 |
| MTH-J-06 | 发布与部署解耦 | 方法论 methodology | 高级 | 把把制品投入运行环境(部署)与让功能对用户可见(发布)分离,使代码可以先部署而暂不启用,功能的开放由运行时开关独立控制。 |
| MTH-J-07 | 可回滚性与爆炸半径控制 | 方法论 methodology | 高级 | 为每次变更预置快速、可靠的恢复能力,并把失败的影响限制在尽可能小的范围:通过制品版本化与路由切换实现快速回滚,通过渐进暴露与故障隔离压缩爆炸半径。 |
| MTH-K-01 | 服务等级目标方法 | 方法论 methodology | 基础 | 用「好事件数 / 总事件数」定义服务水平指标,据此设定低于百分之百的目标值与聚合窗口,并与含后果的协议相区分,把模糊的服务质量转化为可度量、可协商、可决策的目标。 |
| MTH-K-02 | 错误预算政策与燃尽率告警 | 方法论 methodology | 进阶 | 把允许失败量(100% 减去目标)配套为组织政策,明确预算耗尽时的发布、回滚与加固动作;并以多窗口、多燃尽率组合告警,在预算被快速消耗时及时触发干预。 |
| MTH-K-03 | 四大黄金信号监控方法 | 方法论 methodology | 基础 | 面向用户的系统若只能测量四个指标,就选延迟、流量、错误与饱和度;它们覆盖用户感知的核心维度,并以症状而非原因驱动告警,从而在信息有限时仍能及时发现并定位问题。 |
| MTH-K-04 | 可观测性信号关联方法 | 方法论 methodology | 进阶 | 用数值聚合、带上下文的事件记录与请求级路径追踪三类信号共同刻画系统,并通过统一的身份与时间基准把它们关联起来;价值在于信号可相互串联以定位根因,而非信号数量或支柱的划分。 |
| MTH-K-05 | 事件响应与无指责复盘方法 | 方法论 methodology | 进阶 | 以明确的角色分工、活文档与显式交接组织事件响应,尽快缓解影响;事后以无指责复盘聚焦系统性成因、假设参与者基于当时信息善意行事,并把行动项闭环为可验证的改进。 |
| MTH-K-06 | 混沌工程方法 | 方法论 methodology | 高级 | 在生产环境中对系统做受控实验:先定义稳态与假设,再注入真实的动荡变量,比较对照组与实验组的差异以证伪假设,从而主动发现系统性弱点并建立对系统韧性的信心。 |
| MTH-K-07 | 容量规划与变更管理方法 | 方法论 methodology | 高级 | 以意图驱动的方式编码服务依赖与冗余约束、随需求与供给变化自动重算资源计划;同时把发布变更视为首要故障来源,以渐进暴露、分批与门控降低变更风险并测量其效果。 |
| MTH-L-01 | 行为保持重构 | 方法论 methodology | 基础 | 在不改变可观察行为的前提下重组软件内部结构,使其更易理解、更易修改;判定重构是否成立的硬标准是行为不变,治理要点是把小步变换持续进行而非安排一次性大改。 |
| MTH-L-02 | 代码坏味道启发式 | 方法论 methodology | 基础 | 把代码中易于察觉的表层迹象作为可能指向更深层结构问题的启发式信号,用以发现重构对象与时机;坏味道提示「值得检查」,但不等于「一定有问题」,不能机械照改。 |
| MTH-L-03 | 技术债象限与偿还策略 | 方法论 methodology | 进阶 | 以「有意/无意」与「审慎/鲁莽」两组正交判据对债务分诊,据此制定差异化偿还策略:审慎有意者计划偿还,审慎无意者随认知更新修正,鲁莽者立即纠正,并按变更热点优先偿付利息最高的债务。 |
| MTH-L-04 | 演进式架构 | 方法论 methodology | 高级 | 把「有引导的增量变更」确立为跨多个架构维度的首要原则:通过定义架构维度、以可执行机制持续校验合规,并用增量交付验证,使架构能在不失去完整性的前提下持续演化。 |
| MTH-L-05 | 架构适应度函数 | 方法论 methodology | 高级 | 对某些架构特性提供客观完整性评估的可执行机制:把架构意图转写为可判定、可量化的校验,在构建或运行时持续验证,使架构约束不依赖人的记忆与自觉,从而抑制架构漂移。 |
| MTH-L-06 | 遗留系统渐进治理 | 方法论 methodology | 高级 | 对难以安全修改的遗留系统,先以接缝与特征测试建立覆盖既有行为的安全网,再以绞杀者方式增量迁移新功能、逐步替代旧系统,避免缺乏保护的大规模重写。 |
| MTH-L-07 | 弃用与日落策略 | 方法论 methodology | 进阶 | 对将被淘汰的能力采取分级的退场流程:先发出弃用信号并提供替代与迁移路径,留足通知期,再按版本语义区分兼容的弃用与破坏性的移除,从而在收敛接口的同时不破坏既有依赖。 |
| MTH-M-01 | 质量属性战术映射方法 | 方法论 methodology | 进阶 | 战术是影响某项质量属性响应能否达成的设计决策,它直接作用于系统对某类刺激的反应。与模式的区别在于作用范围:战术瞄准单项质量属性的响应,模式描述的是特定语境下反复出现的设计问题及其被验证过的解法,用元素的角色、职责、关系与协作方式来表述。适用边界在于:一条设计决策如果说不清它针对哪类刺激、要改变哪项响应,就还不构成战术,只是普通的实现选择。把每项质量属性目标映射到一组可组合的战术,再由战术组合成架构策略、打包为模式,这一映射的作用是把抽象的质量目标转化为具体、可评审的设计动作。战术位于模式与单条质量属性之间:模式是面向完整问题的打包方案,粒度大、语境强; |
| MTH-M-02 | 可修改性战术应用 | 方法论 methodology | 进阶 | 可修改性指系统在需求或环境变化时,以可接受的代价完成修改的能力。其方法以耦合、内聚与成本动因为依据应用一组战术:推迟绑定时间、局部化变更、防止涟漪效应,使修改集中在局部、缩小受影响模块数与回归风险,从而降低变更成本。判据不是代码是否整齐,而是「改动一个模块时,有多少其它模块必须随之改动」。影响范围由模块之间的相互牵连程度与模块内部职责的聚合程度共同决定:牵连越高、聚合越低,一次改动波及的范围就越广。变更成本等于改动本身的成本加上因耦合被牵连的其它模块的成本,故减少后者往往比减少前者更能显著降低总成本。 |
| MTH-M-03 | 可用性战术应用 | 方法论 methodology | 进阶 | 可用性讨论的起点是把两个词分清:失效指系统不再按规格交付服务,且这一情况能被参与者观察到;故障指可能导致失效的潜在原因。二者是因果而非同义关系,一组故障有可能引发失效,也可能被挡住而不引发。这个区分支撑了整章的策略:战术的作用就是阻止故障演化为失效,或者在无法阻止时把影响限定住,并让修复成为可能。由此也可以解释为什么没有宕机不能证明架构可用——故障可能一直在发生,只是尚未被观察到。围绕这个目标,可用性战术按目的分三类:检测故障、从故障中恢复、预防故障。 |
| MTH-M-04 | 质量模型应用方法 | 方法论 methodology | 进阶 | 以标准化的质量模型(由质量特性与子特性构成的框架)为共同参照,把分散的质量关切组织为可规定、可测量、可评价的维度,并据此在需求、设计与评价之间建立一致的映射。 |
| MTH-M-05 | 可维护性评估方法 | 方法论 methodology | 高级 | 沿可维护性的子特性组织证据,结合结构度量、变更历史与维护过程指标,对系统「修改得有多有效、多高效」做出可比较判断,并据此定位需优先治理的结构问题。 |
| MTH-M-06 | 质量属性权衡决策方法 | 方法论 methodology | 高级 | 面对相互牵制的质量属性,先以场景明确各属性目标与可接受边界,再识别同时影响多个属性的权衡点,通过显式比较与优先级排序做出可解释、可复核、可撤销的决策。质量属性很少能同时最优:为提升性能引入缓存会加剧一致性难度,为增强安全增加校验会拖慢响应,为提高可用性增加冗余会抬高成本与复杂度,为改善可维护性增加抽象会消耗运行期资源。因此架构设计的本质不是让每个属性都最大化,而是在给定语境下选择一组彼此相容的目标,并对冲突处做出有依据的取舍。 |
| MTH-N-01 | 逆向康威操作 | 方法论 methodology | 进阶 | 主动演进团队与组织结构,使其沟通结构对应期望的软件架构,从而让目标架构在组织沟通结构的塑形作用下自然生长,而非在既有组织形态下被扭曲。 |
| MTH-N-02 | 团队拓扑四类型 | 方法论 methodology | 进阶 | 把团队设计约束为四种基本形态——对齐价值流的团队、教练赋能团队、复杂子系统团队与平台团队——借成熟模式引导快速流动,同时以有限类型抑制组织设计的随意性。 |
| MTH-N-03 | 团队交互模式 | 方法论 methodology | 进阶 | 显式定义团队之间的交互方式——限时高带宽协作、清晰边界的服务消费、以及教练式促进——以消除含糊的协调要求,使团队边界的成本与收益可被管理。 |
| MTH-N-04 | 平台团队与最薄可行平台 | 方法论 methodology | 进阶 | 以产品方式建设平台团队,把通用能力封装为可自助使用的内部产品,以降低流对齐团队的认知负荷、加速交付;并以最薄可行平台约束平台规模,避免臃肿平台制造新依赖。 |
| MTH-N-05 | DORA 交付效能指标 | 方法论 methodology | 进阶 | 以一组经过实证的软件交付效能指标——吞吐侧的变更前置时间、部署频率、失败部署恢复时间,与不稳定侧的变更失败率、部署返工率——衡量组织把变更交付到生产的效能,并用于改进而非考核。 |
| MTH-N-06 | 团队边界治理 | 方法论 methodology | 高级 | 把团队边界视为需要持续校准的活对象:以价值流、所有权、认知负荷与交付信号为依据,周期性评估并调整边界与交互方式,防止边界随组织惯性僵化或频繁漂移。 |
| MTH-O-01 | 覆盖与精度的不对称权衡 | 方法论 methodology | 进阶 | 在同一活动中,高覆盖(宁多勿漏)与高精度(宁缺毋滥)此消彼长;因漏失常不可补救而噪声多可过滤,代价不对称,故默认偏向覆盖,再以分层门控逐级精筛。 |
| MTH-O-02 | 准入与触发时机选择 | 方法论 methodology | 进阶 | 决定何时、由谁把产物推进下一环节:人工门控可控但易漏、自动流转高效但可能放行半成品,应在「可信度门槛与发生频率」两个维度上选择人工、自动或半自动策略。 |
| MTH-O-03 | 技术选型的够用原则 | 方法论 methodology | 进阶 | 技术选型方法处理的是在标准、框架、架构风格与外部构件之间做选择的问题:按适用域与约束匹配需求,挑出刚好覆盖质量属性场景的方案,因为任何额外能力都伴随新的复杂度。其判据落在质量属性场景上——在能覆盖当前需求与可预见需求的前提下,选那个其余代价最小的方案,而不是功能清单最长或技术最新潮的那个。它要求同时说清三件事:当前方案满足哪些场景、刻意不满足哪些场景、以及在什么条件下应当改变选择,使选型从一次性拍板变成可持续复核的工程判断。据此,「够用」不是能力上的将就,而是把不产生收益的复杂度明确排除在外。 |
| MTH-O-04 | 能力-成本-速度三角 | 方法论 methodology | 进阶 | 在能力/质量、成本与交付速度之间取舍时,须区分一次性成本与持续成本,先量化各方案的人力、基础设施与运维开销;研究表明速度与稳定可兼得,成本优化的重点应是持续成本与减小变更批量。 |
| MTH-O-05 | 质量属性冲突治理 | 方法论 methodology | 高级 | 质量属性冲突治理,指在架构决策过程中把多个质量属性之间此消彼长的关系从隐性经验转为显式可裁决对象的成套做法。它处理的不是单个属性如何达成,而是当若干属性同时提出要求、且这些要求由同一批设计决策承载时,如何给出有依据、可追溯、可重议的取舍。这里的治理一词有两重含义:一是承认冲突的常态化,不把「所有属性同时最优」当作可追求的目标;二是把处理冲突的动作固定成流程,使结论不依赖某一次讨论中谁的声音更大。它的治理单位是场景而不是属性名词:属性只有被写成带刺激、环境与响应度量的场景之后,才可能被比较、被排序、被判为达成或未达成;离开场景,「性能好」「安全性高」这类表述无法支撑任何裁决。 |
| MTH-O-06 | 粒度与边界设定 | 方法论 methodology | 高级 | 决定模块、服务、知识域与团队按什么分解、切到多细:应围绕可能变化的设计决策(信息隐藏)而非处理步骤切分,用内聚耦合度量与认知负荷约束边界,并使架构边界与团队边界同步演化。 |
| MTH-O-07 | 自动化方式选择 | 方法论 methodology | 进阶 | 在规则/模板、模型生成与纯人工之间选择实现方式:模板与规则零成本且可控,模型与自动化适合高频或复杂场景;应按沉淀粒度与可信度门槛选择,并为自动化配置持续执行与反馈闭环。 |
| MTH-O-08 | 复杂度阶梯与演进时机 | 方法论 methodology | 进阶 | 在简单与复杂方案之间选择与进阶时机:复杂方案的建设、延迟与一致性成本更高,应先跑通最简单可工作的方案,待出现明确且当前的跨域或规模需求时再逐步演进,而非为预想的未来提前复杂化。 |
| MTH-O-09 | 理解成本优先的简单原则 | 方法论 methodology | 进阶 | 这里的简单性指采用人们熟悉且前后一致的模式与结构,使新加入的工程师也能较快理解系统,而不是指功能数量少。书中把简单性列为可维护性的三根支柱之一,与可运维性、可演化性并列,理由很直接:维护成本占据软件生命周期支出的大头,而复杂度会让每一个改动系统的人都变慢,进而推高维护成本。判别困难也写得很诚实——是否简单带有主观成分,缺少客观刻度,因此同一个系统可以因为把复杂实现藏在简单接口之后而被认为简单,也可以因为实现本身直白却暴露大量内部细节而被认为复杂。所以简单性应作为设计目标显式提出,并接受它需要靠判断而非靠计数来裁定,也需要在评审中被反复追问,而不是默认它已经成立。 |
| MTH-O-10 | 增量演化与一致性治理 | 方法论 methodology | 高级 | 在演化中治理一致性:优先用增量同步、契约与弃用信号替代全量重建,用适应度函数持续防止架构漂移,并以 expand/contract、绞杀者等模式渐进迁移,使变更小批量、可回退。 |
| MTH-O-11 | 度量与反馈闭环 | 方法论 methodology | 高级 | 建立轻量、客观、可复现的评估体系与反馈闭环:用真实场景与基线度量、以多指标协同避免单点失真,并把度量接入持续执行与复测;同时警惕古德哈特定律,防止指标一旦成为目标即被博弈。 |
| MTH-G-05 | 架构文档化方法 | 方法论 methodology | 进阶 | 以「文档化相关视图,再文档化适用于多个视图的信息」为组织原则的架构文档化方法:先按预期用途与干系人关注选择视图,再表达每个视图的「如何组织、架构是什么、为何如此」,并以跨视图信息与一致性校验避免文档过载与失真。 |
| MTH-G-06 | 效用树与敏感点权衡点分析 | 方法论 methodology | 高级 | 把质量属性自顶向下细化为带刺激与响应度量的场景并排序,形成效用树;再沿树把架构决策逐条映射到场景上,标出对单一属性响应影响显著者与同时反向影响多项者,并归纳风险主题。它把笼统的质量目标变成可探测、可排序、可聚焦的风险清单。效用树的结构可以逐层读出:根节点表示系统整体的好,其下一层列出该系统必须呈现的主要质量属性,再下一层把每个属性细化为与本系统相关的具体侧面,叶片位置放的是以刺激与响应度量写成的场景。它之所以被设计成树而非清单,是因为自顶向下逐层收窄能把笼统的属性名逼到可判定的场景,避免停留在可修改、高吞吐这类无法验收的层面。 |
| MTH-H-03 | 战略式编程与持续设计投入 | 方法论 methodology | 进阶 | 一种把系统设计视为贯穿开发全过程的持续投入、而非开工前一次性阶段的编程纪律:以持续、小步的设计改进对抗复杂度的累积,使系统长期保持易于理解与修改。 |
| MTH-H-04 | 代码复审与可读性治理 | 方法论 methodology | 进阶 | 以评审流程把可读性与结构标准组织化、可教学地传播的治理方法:把代码评审从个人偏好检查转为有依据、有导师机制的常规活动,在变更合入前对结构、接口与可读性施加统一约束。 |
| MTH-G-01 | 架构决策记录 | 方法论 methodology | 基础 | 把每个架构上重要的决策记录为短文本文件(含上下文、决策、状态与后果),使决策依据、取舍与被否决的备选可被追溯、复核与取代,而非散落在会议记录与个人记忆中。 |
| MTH-G-02 | 质量属性场景与ATAM | 方法论 methodology | 进阶 | 质量属性场景是把「快」「稳」「可改」这类说法转成可验收需求的固定格式,共六个位置:谁发出刺激、刺激是什么、处于什么环境、作用于哪个制品、系统应给出什么响应、响应用什么度量判定。它的价值在于绕开两个常见麻烦——属性定义本身不可测,以及同一现象被不同属性社群各自认领。两个补充限定:六个位置在早期常被省略,但知道它们存在会迫使设计者逐项确认是否真的不相关;响应度量是整条场景能否被验收的关键,缺了它场景就退化为愿望。因此场景既不是模板填空的产物,也不是需求的替代物,而是把质量诉求推到可判定状态的载体。 |
| MTH-G-03 | 架构风格选择方法 | 方法论 methodology | 高级 | 架构风格可理解为对一类系统组织方式的命名与约定:风格固定了可用构件的种类、连接方式的种类,以及二者允许如何拼装。选型方法则以质量属性场景为判据,把候选风格的构件—连接件约束逐项映射为属性收益与代价,在具体子域上择优,而非寻找普适最优。其要点有三:其一,风格的本质是约束集合,符合约束才带来特定属性,而约束一旦采纳,包里每项战术的收益与副作用同时生效,且通常不只作用于一项质量属性;其二,同一风格在不同子域、不同负载形态与不同规模下,收益与代价可能整体反转,故不存在放之四海皆准的答案,只能就事论事地评估;其三,落锤前必须把代价显性化,说清放松哪条约束换取哪项属性。 |
| MTH-G-04 | 领域驱动战略设计 | 方法论 methodology | 高级 | 以限界上下文显式划定模型适用边界、以通用语言在单个上下文内统一团队与代码的表达,并通过上下文映射管理跨上下文关系的领域建模战略方法。 |
| MTH-H-01 | 重构手法族 | 方法论 methodology | 进阶 | 在不改变可观察行为的前提下,按命名的小步手法持续改善代码内部结构的方法族;以代码坏味道为信号、以测试为安全网,把结构调整为可验证的小步而非大重写。 |
| MTH-H-02 | 信息隐藏模块化分解 | 方法论 methodology | 进阶 | 以「隐藏困难或可能变化的设计决策(secret)」为判据,把同一 secret 相关行为归入一个模块、仅经最小接口交互的分解方法,使变更局部化。 |
§3组内关系图
前置依赖实现依据推导案例印证对比冲突
§4学习路径提示
本组内存在 18 条前置依赖边(prerequisite),推荐先掌握前置知识点,再进入依赖它的节点。
推荐阅读顺序(拓扑序)
需求工程过程 → 干系人识别与分析 → 功能与非功能需求分类 → 领域驱动战略设计 → 架构文档化方法 → 效用树与敏感点权衡点分析 → 重构手法族 → 信息隐藏模块化分解 → 战略式编程与持续设计投入 → 代码复审与可读性治理 → 测试驱动开发 → 质量门控与持续集成 → 封闭构建 → 配置外置与显式化 → 渐进暴露部署策略 → 可回滚性与爆炸半径控制 → 四大黄金信号监控方法 → 混沌工程方法 → 容量规划与变更管理方法 → 代码坏味道启发式 → 技术债象限与偿还策略 → 架构适应度函数 → 遗留系统渐进治理 → 可修改性战术应用 → 可用性战术应用 → 可维护性评估方法 → 质量属性权衡决策方法 → 逆向康威操作 → 平台团队与最薄可行平台 → DORA 交付效能指标 → 团队边界治理 → 准入与触发时机选择 → 能力-成本-速度三角 → 质量属性冲突治理 → 复杂度阶梯与演进时机 → 增量演化与一致性治理 → 需求获取 → 质量属性场景与ATAM → 测试替身与测试策略 → 测试金字塔与反模式 → 软件测试过程模型 → 部署流水线 → 发布与部署解耦 → 可观测性信号关联方法 → 事件响应与无指责复盘方法 → 演进式架构 → 行为保持重构 → 弃用与日落策略 → 质量模型应用方法 → 质量属性战术映射方法 → 团队拓扑四类型 → 自动化方式选择 → 粒度与边界设定 → 技术选型的够用原则 → 理解成本优先的简单原则 → 度量与反馈闭环 → 需求规格说明 → 架构决策记录 → 架构风格选择方法 → 测试层次 → 发布工程 → 错误预算政策与燃尽率告警 → 团队交互模式 → 覆盖与精度的不对称权衡 → 需求属性与优先级 → 测试类型 → 服务等级目标方法
- 干系人识别与分析 → 需求获取先识别干系人再开展需求获取
- 需求工程过程 → 需求获取需求工程过程包含需求获取活动
- 需求获取 → 需求规格说明获取到的需要需经规格化形成信息项
- 功能与非功能需求分类 → 需求规格说明需求分类是规格说明的结构化前提
- 需求规格说明 → 需求属性与优先级规格化后按属性与优先级管理需求
- 测试层次 → 测试类型测试层次是应用测试类型的结构前提
- 配置外置与显式化 → 部署流水线配置外置是流水线逐环境提升同一制品的前提
- 事件响应与无指责复盘方法 → 错误预算政策与燃尽率告警事件响应决策依赖错误预算政策
- 混沌工程方法 → 事件响应与无指责复盘方法事件复盘证据驱动混沌实验设计
- 代码坏味道启发式 → 行为保持重构坏味道作为启发式信号触发重构
- 遗留系统渐进治理 → 行为保持重构改动遗留代码前先建立行为安全网
- 遗留系统渐进治理 → 弃用与日落策略遗留治理与弃用共享迁移路径设计
- 质量属性权衡决策方法 → 质量属性战术映射方法战术映射是权衡决策的前置输入
- 逆向康威操作 → 团队拓扑四类型逆向康威操作以团队拓扑为结构模板
- 度量与反馈闭环 → 覆盖与精度的不对称权衡度量口径是覆盖与精度取舍的前置
- 能力-成本-速度三角 → 技术选型的够用原则成本量化是选型匹配的前置输入
- 质量属性场景与ATAM → 架构决策记录识别敏感点与权衡点是记录架构决策的前提
- 质量属性场景与ATAM → 架构风格选择方法质量属性场景与评估是风格权衡选型的前置分析