小周和小林终于看中了市中心一套老房子。中介算了一笔账:全款买要再攒十年,贷款的话,下个月就能搬进去。他们选了贷款。从此,每个月工资到账先划走一笔月供,二十年下来,付给银行的利息几乎能再买半套房。这个场景,做技术选型的你是否似曾相识?为了抢一个功能上线,选了“先凑合”的方案;为了赶一个项目节点,跳过了重构和测试——这些“凑合”与“跳过”,技术圈称之为技术债务。它和房贷一样:让你今天走得快,却要你未来慢慢还,还要连本带利。 本文就用小周和小林的买房装修故事,讲清楚技术债务的本质、分类、评估维度、风险量化,以及开源与自研的权衡之策。读完你会明白:技术债务不是洪水猛兽,而是一笔需要像管家记账一样认真经营的“技术贷款”——用好了它是撬动交付速度的杠杆,用不好它会成为拖垮团队的包袱。

岗位关联

掌握技术债务的评估与决策方法,你就能在 AI 技术选型中看清三五年后的维护成本,避免亲手埋下让团队寸步难行的“定时炸弹”——这是普通工程师与架构师的分水岭。

目录
  1. 可视化演示
  2. 技术债务本质
  3. 债务类型辨析
  4. 评估维度框架
  5. 风险量化评估
  6. 开源自研权衡
  7. 管理策略选择
  8. 落地实践指南
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示技术债务的分类识别、量化评估与偿还策略,切换模式观察债务从分类到偿还的全流程管理。

本节配有交互动效(进入视口后自动加载,约 3KB)。

技术债务四类分类 代码债务:高复杂度函数、重复代码块、过时依赖 数据/模型/架构债务各有不同识别方式与影响范围 Debt = Code + Data + Model + Architecture 技术债务如同信用卡欠款需系统分类管理

技术债务本质

小周和小林看中了市中心一套老房子,中介说全款太吃力,建议贷款。贷了款,他们今天就能搬进新家;代价是未来二十年每个月都要从工资里划出一笔月供。技术选型的世界里也有这种“先享受、后还款”的安排:为了抢上线时间,选了一个“临时但省事”的方案,欠下的改造工作,就是技术圈常说的技术债务。

这个概念最早由计算机科学家 Ward Cunningham 提出。他打了一个比方:写代码就像借钱,图快而走捷径,等于向未来的自己借钱。技术债务有三个核心要素:本金——把临时方案改造成健康方案需要投入的人天;利息——因为方案不完善,每天、每个版本额外付出的维护成本;时间——债务从产生到还清所持续的年数,拖得越久,利息滚得越大。

把多项债务的利息累加起来,就得到一个可以横向比较的数字:

小周后来想通了一件事:房贷不是洪水猛兽,关键是利息能不能承受。技术选型也一样——从来没有债务的团队往往保守得不敢创新,适度负债恰恰是抢占市场的杠杆。真正要警惕的,是那些“利率高得离谱”的债。

技术债务总量=∑i=1n(本金i×利息率i×持续时间i)\displaystyle 技术债务总量 = \sum_{i=1}^{n}\left(本金_i \times 利息率_i \times 持续时间_i\right)
公式通俗说明:就像房贷总利息等于每笔贷款金额 × 年利率 × 还款年数,技术债务总量就是把每一笔“技术贷款”的利息全部加在一起,用来衡量系统整体背负的包袱有多重。
  1. 本金项第 \(i\) 项债务的“借款额”,即把临时方案改造成健康方案所需的人天。
    本金i=重构人天数\displaystyle 本金_i = 重构人天数
  2. 利息率项每年因债务存在而额外多花的维护成本比例,例如每改一个功能都要多花 30% 时间绕开老坑。
    利息率i=年额外维护人天本金i\displaystyle 利息率_i = \frac{年额外维护人天}{本金_i}
  3. 持续时间项这笔债从产生到还清经过的年数,时间越长,复利效应越恐怖。
    持续时间i=还清年份−产生年份\displaystyle 持续时间_i = 还清年份 - 产生年份
  4. 求和符号把 \(n\) 笔债务的利息全部累加,得到整个系统的技术债务总量。
    ∑i=1n(⋯ )\displaystyle \sum_{i=1}^{n}(\cdots)

债务类型辨析

搬进老房子之后,小两口发现家里的负债不止房贷:装修时刷爆了信用卡,搬家时借了朋友的人情,买家电还办了分期。每种债的“利息”完全不同——信用卡年利率接近 18%,朋友的人情债靠请客吃饭就能还,绝不能混为一谈。

技术债务也分四类。代码债务是最常见的一种:命名混乱、复制粘贴的代码逻辑,每读一次都要多烧几分钟脑细胞。架构债务最隐蔽:模块之间你中有我、我中有你,每次改动都像拆炸弹,牵一发而动全身。测试债务最危险:自动化测试缺失,每次发版都靠人肉点点点,回归一遍要加班一周。文档债务最磨人:接口文档停在两年前,新人接手全靠猜,资深工程师被迫一遍遍当“人肉文档”。

用“需要重构的模块占比”可以粗略度量整体健康度:

小周把债务分了类,发现装修时“图省事”用的劣质电线是最贵的债——它既是架构债务,又带安全隐患。分类的目的从来不是贴标签,而是识别出哪些债正在悄悄烧钱,哪些债可以暂时放着不管。

债务比率=需要重构的模块数系统总模块数\displaystyle 债务比率 = \frac{需要重构的模块数}{系统总模块数}
公式通俗说明:就像盘点家里“需要大修的地方”占总面积的比重,债务比率越高,说明这套系统翻修起来越费劲。
  1. 分子定义根据代码评审中发现的低内聚、高耦合等信号,判定为“不健康”的模块数量。
    需要重构的模块数=各模块评审标记数之和\displaystyle 需要重构的模块数 = 各模块评审标记数之和
  2. 分母定义当前系统的全部业务模块与技术模块的总数。
    系统总模块数=全部可独立交付的模块计数\displaystyle 系统总模块数 = 全部可独立交付的模块计数
  3. 比值含义用 0-1 之间的小数反映代码库的健康度,0.2 以下算健康,0.5 以上就该警惕了。
    债务比率∈[0,1]\displaystyle 债务比率 \in [0, 1]

评估维度框架

办房贷时,小周研究过好几家银行:有的利率低但违约金高,有的放款快但额度小。他列了一张表,逐项打分,才做出决定。评估一笔技术债务,同样需要多维度的“贷款审查”。

常用的评估框架包含四个维度。偿还成本:把债还清需要一次性投入多少重构人天。利息率:债务每天产生多少额外维护成本,是“慢刀子割肉”还是“小打小闹”。到期风险:什么时候会爆雷——比如遇到大版本升级、流量洪峰或关键人员离职。战略价值:还清这笔债之后,对业务长期发展有什么好处。

为了让多个方案在同一个天平上比较,可以加权打分:

小周用四个维度给老房子的“水电改造”打分:偿还成本高,但利息极高、风险极大、战略价值大——结论很明确,这笔债必须排进预算。评估维度就是家庭理财里的“哪张卡先还”,有了框架,就不用拍脑袋。

综合评分=w1s1+w2s2+w3s3+w4s4\displaystyle 综合评分 = w_1 s_1 + w_2 s_2 + w_3 s_3 + w_4 s_4
公式通俗说明:就像给银行打分时,把“利率、手续费、额度、放款速度”按自己看重的程度配权重,综合分高的方案优先考虑。技术债务里,综合分高的那笔债应该优先处理。
  1. 维度得分\(s_1\) 到 \(s_4\) 分别对应偿还成本、利息率、到期风险、战略价值的归一化得分,取值 0-1。
    sj∈[0,1], j=1,2,3,4\displaystyle s_j \in [0, 1],\ j=1,2,3,4
  2. 权重系数\(w_1\) 到 \(w_4\) 是团队根据业务目标设定的权重,体现“什么对你更重要”。
    w1+w2+w3+w4=1\displaystyle w_1 + w_2 + w_3 + w_4 = 1
  3. 加权求和把四个维度折算成一个总分,避免“单维度优秀、整体糟糕”的误判。
    综合评分∈[0,1]\displaystyle 综合评分 \in [0, 1]

风险量化评估

装修队提醒小周:老房子的电线还是二十年前的铝线,着火的概率不算高,但真出了事,烧掉的是整个家。小周意识到,判断一笔债要不要还,不能只看“现在痛不痛”,还要看“未来会不会爆”。

技术债务的风险可以用一个经典公式量化:风险 = 概率 × 影响。概率指债务在可预见的未来触发问题的可能性——这个模块会不会频繁改动?这套接口会不会遭遇流量高峰?影响指问题真正发生后的损失——故障停机损失多少营收?修复要投入多少人天?此外还有一个乘数:时间紧迫度,距离“爆雷点”越近,紧迫度越接近 1,风险被进一步放大。

小周给每项债务做了个风险排行榜,发现“看起来最吵的墙纸开裂”其实是小问题,而“静悄悄的铝线”才是头号危险。量化让直觉无处遁形——这也是技术负责人最该有的思维方式。

风险值=发生概率×影响程度×时间紧迫度\displaystyle 风险值 = 发生概率 \times 影响程度 \times 时间紧迫度
公式通俗说明:就像评估“老房子起火”的风险,铝线的起火概率乘上“烧掉整个家”的损失,再乘上“两年内必须大检查”的紧迫度,才能得到真实的风险值。
  1. 发生概率债务在未来触发问题的可能性,来自历史故障频率与团队经验的判断,取值 0-1。
    发生概率=P(问题发生)\displaystyle 发生概率 = P(问题发生)
  2. 影响程度问题发生后的损失量,单位为人天,含故障修复工时与业务损失折算。
    影响程度=修复人天+业务损失折合人天\displaystyle 影响程度 = 修复人天 + 业务损失折合人天
  3. 时间紧迫度距离债务“爆雷”节点的剩余时间系数,剩余时间越短,系数越接近 1。
    时间紧迫度∈(0,1]\displaystyle 时间紧迫度 \in (0, 1]

开源自研权衡

装修到买家具环节,小周转遍了家具城:网上买成品柜子,便宜、三天到货,但尺寸不一定契合墙角;找木匠定制,严丝合缝、板材任选,但要等一个月,价格翻倍。“开源与自研”的对决,本质上就是“成品与定制”的较量。

开源方案像成品家具:省去了从头制作的初始成本,社区就是“大厂生产线”,生态成熟、上手快;但定制改造困难,上游拍板的路线你只能跟随,万一社区停摆,相当于“厂商倒闭”。自研方案像定制家具:完全按需设计、可控性强,但初始开发成本和长期维护都得自己扛,一个不小心就背上沉重的架构债务。

两者的优劣不能凭感觉,要看全生命周期的总拥有成本:

小周转了一圈得出结论:卧室衣柜买成品足够,书房那面异形墙必须定制。技术选型同理——通用需求上开源,核心竞争处自研,这本身就是一种把债务最小化的智慧。

总拥有成本=初始成本+年均维护成本×使用年限\displaystyle 总拥有成本 = 初始成本 + 年均维护成本 \times 使用年限
公式通俗说明:就像买家具不能只看标价,还要算上保养、维修、几年后换新的钱。开源方案可能“标价”低,但长期维护的人天未必划算。
  1. 初始成本方案落地所需的一次性投入,包括选型调研、环境搭建、代码开发与集成。
    初始成本=选型人天+开发人天+集成人天\displaystyle 初始成本 = 选型人天 + 开发人天 + 集成人天
  2. 年均维护成本每年用于升级、修 bug、运维的平均人天投入。
    年均维护成本=全年维护总人天1\displaystyle 年均维护成本 = \frac{全年维护总人天}{1}
  3. 使用年限方案预期服役的年数,技术选型中一般取 3-5 年。
    使用年限≈3∼5 年\displaystyle 使用年限 \approx 3 \sim 5\ 年
  4. 相乘累加把一次性投入与多年维护投入加总,得到全生命周期总成本。
    TCO=初始成本+维护成本×年限\displaystyle TCO = 初始成本 + 维护成本 \times 年限

管理策略选择

搬进新家一年后,小两口拿到年终奖,面对房贷有四种选择:提前还款省利息、转贷换低利率、申请展期缓口气、或者按原计划慢慢还。技术债务的管理,恰好也有这四招。

主动偿还:集中一个迭代专门重构,把债务连根拔起,利息从此归零。债务展期:承认债在那里,但把重构推迟到版本大升级或业务淡季的窗口期。债务重组:干脆换技术栈、换架构,旧系统“破产清算”,重新来过。接受共存:有些债是战略性的——比如为了抢市场选用的临时方案,明知道要还,但业务价值远大于利息,于是长期持有并控制它的边界。

面对多笔债务,还哪笔先?用“每投入一天能消灭多少利息”来排序:

小周算了笔账:信用卡年利率 18%,房贷年利率 4%,当然先还信用卡。技术债务同理——高利率的债优先还,低利率的债可以慢慢来,这就是管理策略的核心心法。

偿还优先级=年利息额单次偿还成本\displaystyle 偿还优先级 = \frac{年利息额}{单次偿还成本}
公式通俗说明:就像还债先还高利率的信用卡,而不是低利率的房贷。技术债务里,每投入一天重构能省下的利息越多,优先级就越高。
  1. 年利息额该项债务每年造成的额外维护人天,等于本金乘以利息率。
    年利息额=本金×利息率\displaystyle 年利息额 = 本金 \times 利息率
  2. 单次偿还成本完成一次重构所需的一次性投入人天。
    单次偿还成本=重构总人天\displaystyle 单次偿还成本 = 重构总人天
  3. 比值排序用单位投入的“减息效率”给所有债务排队,效率最高的先还。
    优先级=年利息额偿还成本\displaystyle 优先级 = \frac{年利息额}{偿还成本}

落地实践指南

第二年起,小周和小林养成了习惯:每月记账、每季度盘点家庭资产、每年做一次全面体检。管债务不是搬进新家那天就结束的,而是融入日常的持续动作。技术团队想把债务管好,也有一套可复制的实践。

第一步,建立债务清单:每一项债务都记录本金、利率、产生时间、负责人,让债务“看得见”。第二步,设置预算配额:每个迭代留出固定比例工时专门还债,保证新债不失控、旧债有人在还。第三步,定期技术体检:在架构评审和 Code Review 中识别新增债务,防止“隐性负债”悄悄膨胀。第四步,迭代治理:每轮迭代还一小笔,像还信用卡最低还款额一样细水长流。

预算配额的具体数值可以这样定:

小周现在常说:我们不是不负债,而是让每一笔债都在账本上、都有还款计划。技术团队也一样,把债务纳入日常治理,选型时的冲动就会被长期主义的纪律驯服。管好债务,才敢大胆创新。

债务预算=团队总开发工时×预留比例\displaystyle 债务预算 = 团队总开发工时 \times 预留比例
公式通俗说明:就像小两口约定“每月工资的 20% 强制储蓄还贷”,团队也约定每次迭代 10%-20% 的工时专门用于偿还技术债,长期坚持,债务余额必然下降。
  1. 总开发工时一个迭代周期内团队全部可用人天。
    团队总开发工时=开发人数×迭代天数\displaystyle 团队总开发工时 = 开发人数 \times 迭代天数
  2. 预留比例管理层认可的技术债务偿还占比,业界实践经验建议 10%-20%。
    预留比例∈[0.1,0.2]\displaystyle 预留比例 \in [0.1, 0.2]
  3. 预算结果每轮迭代必须固定投入的“还债”工时,用于保证债务只减不增。
    债务预算=总工时×预留比例\displaystyle 债务预算 = 总工时 \times 预留比例

AI 应用场景

大模型推理框架选型

阶段:技术选型与架构设计

解决的问题:自研推理引擎虽然贴合业务,但每轮大模型升级都要“还旧账”,临时补丁越堆越多;开源推理框架初始成本低、社区迭代快,却被质疑定制困难。用 TCO 公式和债务四维度评估后,团队不再凭感觉拍板。

具体案例:某 AI 公司上线大模型服务,自研引擎已积累约 300 人天的架构债务。团队计算出三年 TCO:自研约 900 人天,迁移到开源方案约 650 人天,最终决定迁移,并把自研期间的优化以 Pull Request 回馈社区,把“债务”变成了社区影响力。

特征平台迁移决策

阶段:数据平台选型

解决的问题:自研特征存储存在严重的测试债务与文档债务,每次新特征上线都靠人工验证,风险持续累积;开源 feature store 社区活跃,但迁移成本不明。团队用风险量化矩阵评估,找到“概率中等、影响巨大”的关键债务,决定采用债务重组策略。

具体案例:某推荐系统团队在过渡期采用“双跑”方案:新旧平台并行运行三个月,用自动化对比脚本验证特征一致性,再按模块分批切换。最终迁移完成时,测试债务从 80% 的模块无用例下降到 15%,发版回归时间缩短了 60%。

Python 演示

python51 行
# -*- coding: utf-8 -*-"""技术债务模拟器:计算每笔债务的利息与偿还优先级"""  class TechDebtItem:    def __init__(self, name, principal, rate, years):        self.name = name               # 债务名称        self.principal = principal     # 债务本金(重构所需人天)        self.rate = rate               # 年利息率(额外维护比例)        self.years = years             # 债务持续年数     def interest_paid(self):        """累计利息 = 本金 * 利息率 * 年数"""        return self.principal * self.rate * self.years     def total_cost(self):        """总成本 = 本金 + 累计利息"""        return self.principal + self.interest_paid()     def priority(self):        """偿还优先级 = 年利息额 / 单次偿还成本"""        annual_interest = self.principal * self.rate        return annual_interest / self.principal  def build_debt_list():    """构造三项典型技术债务"""    return [        TechDebtItem("旧版参数服务器", 60, 0.25, 3),        TechDebtItem("缺失的模型测试", 20, 0.40, 2),        TechDebtItem("过时的API文档", 10, 0.05, 1),    ]  def report(debts):    """输出技术债务评估报告"""    print("技术债务评估报告")    print("====================")    for d in debts:        print("债务[%s]: 本金=%d人天, 利率=%.0f%%, 累计利息=%d人天, 总成本=%d人天"              % (d.name, d.principal, d.rate * 100,                 d.interest_paid(), d.total_cost()))    total_interest = sum(d.interest_paid() for d in debts)    print("若全部按期延后,总利息支出为 %d 人天" % total_interest)    print("建议偿还顺序(利率高者优先):")    for d in sorted(debts, key=lambda x: x.priority(), reverse=True):        print("  1. %s(优先级 %.2f)" % (d.name, d.priority()))  if __name__ == "__main__":    report(build_debt_list())
目的:把正文中的债务计算公式落地成一个小工具,输入每笔债务的本金、利率和年限,自动输出累计利息、总成本,并给出“先还哪笔”的优先级排序。
  1. self.rate = rate把年利息率存进对象,后续所有利息计算都以此为基础。
  2. return self.principal * self.rate * self.years这就是正文里的利息公式,模拟债务随时间滚动的积累。
  3. annual_interest / self.principal用“每投入 1 人天还债能消灭多少年利息”作为优先级,利率越高越靠前。
  4. sorted(debts, key=lambda x: x.priority(), reverse=True)按优先级从高到低排序,直接输出建议的还债顺序。
  5. if __name__ == "__main__":保证脚本既能被 import 复用,也能直接运行输出报告。

常见误区

误区“技术债务说白了就是代码乱、注释少、命名差,多搞几次 Code Review、统一代码风格就能解决。”

正解代码风格只是最表层的一类债务。技术债务还包括架构耦合、测试缺失、文档过期,本质是“决策层面欠下的账”,而不是“书写层面的脏乱”。就像房贷不是“家里乱”造成的,而是当初选择了贷款买房这个决策。光靠格式化代码,还不了架构债务的“月供”。

为何常见:因为代码债务是最直观、最常见的一类,初学者很容易用它以偏概全,忽略了更昂贵的架构与测试债务。

误区“技术债是坏事,一个优秀的团队应该追求零债务,任何凑合方案都不能接受。”

正解零债务往往意味着过度设计——为永远用不上的扩展性反复建设,反而拖慢了交付。适当的技术债务是“用未来的钱换现在的速度”,只要利率可控就是划算的杠杆。真正该消灭的是高利率债务,而不是债务本身。就像小周买房,不贷款就永远攒不够首付。

为何常见:因为“债务”一词天然带负面色彩,让人忽略了它的杠杆价值,走向另一个极端。

误区“开源框架免费下载,用的人多、资料全,肯定比自研省钱,选它就稳赚不赔。”

正解开源省下的只是“初始成本”,学习成本、集成成本、二次开发成本、跟随上游升级的维护成本都要算进 TCO。更别说社区停摆、许可证变更等隐性风险。开源不是零成本,而是把成本换了一种形式,甚至可能带来“选型即负债”的窘境。

为何常见:只盯着“免费”两个字,忽视了软件全生命周期里的隐性维护投入。

误区“我们做选型的时候哪有什么技术债?债务都是后来写代码慢慢欠下的,选型管不着。”

正解选型本身就决定了债务的上限:选一个社区凋零的框架,等于一开始就背上高利息贷款;选一个文档残缺的库,等于刚搬进新家就要开始还账。技术选型正是债务的“发卡时刻”,贷不贷、贷多少、利率几何,在签字那一刻就已经定下。

为何常见:因为债务的利息在使用阶段才逐渐显现,容易让人误以为源头在使用而非选择。

面试题

Q1. “技术债务”这一概念最早由谁正式提出?

单选题 · easy

  • A.沃德·坎宁安← 正确答案
  • B.马丁·福勒
  • C.肯特·贝克
  • D.埃里克·伽马

答案:A。Ward Cunningham 在 1992 年首次提出“技术债务”隐喻,用金融借贷类比代码中的捷径。Martin Fowler 是重构与设计模式的倡导者,Kent Beck 是极限编程与 TDD 的代表,Erich Gamma 是设计模式四人组之一,他们虽然都推动了软件工程实践,但都不是技术债务概念的提出者。

Q2. 以下哪些属于技术债务的常见类型?

多选题 · easy

  • A.代码债务与架构债务← 正确答案
  • B.测试债务与文档债务← 正确答案
  • C.采购债务与场地债务
  • D.招聘债务与培训债务

答案:AB。技术债务按来源通常分为四类:代码债务(命名混乱、复制粘贴)、架构债务(模块耦合)、测试债务(用例缺失)、文档债务(文档过期)。采购、场地属于资产采购范畴,招聘、培训属于人力管理范畴,都不属于技术债务的经典分类。

Q3. 两笔技术债务利息率相同,本金更大的那笔应该如何处理?

单选题 · mid

  • A.优先偿还并降低利息损失← 正确答案
  • B.延后偿还以免影响业务
  • C.直接删除相关功能模块
  • D.保持现状不做任何干预

答案:A。在利息率相同的情况下,本金越大,每年产生的绝对利息额越高,优先偿还它能节省最多的累计利息。这和还房贷一个道理:同利率下先还大额贷款更划算。删除功能模块属于功能决策而非债务管理,延后与不干预都会让大额本金继续滚利息。

Q4. 自研方案初始成本 200 人天、年均维护 20 人天;开源方案初始成本 60 人天、年均维护 50 人天。按 TCO 公式,大约使用多少年后自研更划算?

单选题 · mid

  • A.使用 3 年后自研更划算
  • B.约 5 年后自研更划算← 正确答案
  • C.开源方案始终更划算
  • D.两者成本始终完全相同

答案:B。设使用年限为 y,自研 TCO=200+20y,开源 TCO=60+50y。令两者相等:200+20y=60+50y,解得 y≈4.67 年。因此约 5 年后自研的累计成本开始低于开源。这正是 TCO 公式的典型应用:短期开源便宜,长期自研可能更划算。

Q5. 评估技术债务通常需要考察哪些维度?

多选题 · mid

  • A.偿还成本与利息率水平← 正确答案
  • B.到期风险与战略价值← 正确答案
  • C.代码行数与注释数量
  • D.团队成员数量与工龄

答案:AB。技术债务的经典评估四维度是偿还成本、利息率、到期风险与战略价值。代码行数与注释数量只是代码债务的表面指标,不能作为独立评估维度;团队人数与工龄属于人力资源管理范畴,与技术债务的债务属性无关。

Q6. 一项技术债务本金 40 人天,年利息率 30%,持续 2 年未处理,累计利息是多少?

单选题 · hard

  • A.约 24 人天← 正确答案
  • B.约 40 人天
  • C.约 12 人天
  • D.约 32 人天

答案:A。根据利息公式“累计利息 = 本金 × 利息率 × 持续时间”,代入 40 × 0.3 × 2 = 24 人天。40 人天是本金本身,12 人天是只算了一年的利息,32 人天是本金的 80% 无依据。这题考察对利息公式三要素的准确记忆。

Q7. 与自研方案相比,开源方案最典型的优势是什么?

单选题 · easy

  • A.社区生态成熟上手速度快← 正确答案
  • B.完全不受任何许可约束
  • C.技术路线永远由我方掌控
  • D.不需要任何学习与维护成本

答案:A。开源方案的最大优势是社区生态成熟,踩坑有前人、问题有答案,上手速度快。开源同样受许可证约束,路线由社区掌控而非我方,且存在学习与维护成本——B、C、D 这三个说法都是对开源的理想化误解。

Q8. 以下哪些属于常见的四种技术债务管理策略?

多选题 · mid

  • A.主动偿还与债务展期← 正确答案
  • B.债务重组与接受共存← 正确答案
  • C.删除代码与关闭仓库
  • D.停止交付与解散团队

答案:AB。四种经典策略是主动偿还(集中重构)、债务展期(推迟到合适窗口)、债务重组(换技术栈)与接受共存(战略性持有)。删除代码、关闭仓库、停止交付、解散团队都是极端管理动作,不属于常规意义上的债务管理策略。

Q9. 风险计算公式为“概率 × 影响 × 紧迫度”。某模块崩溃概率 0.4,影响 60 人天,紧迫度 1.0,风险值是多少?

单选题 · hard

  • A.24 人天← 正确答案
  • B.60 人天
  • C.40 人天
  • D.48 人天

答案:A。代入公式:0.4 × 60 × 1.0 = 24 人天。60 是影响程度本身,40 是概率与本金类数值的混淆,48 是把概率误算成 0.8 的结果。风险量化要求把概率、影响、紧迫度三者相乘,缺一不可。

Q10. 以下哪种情况最适合定义为“战略性技术债务”?

单选题 · extreme

  • A.为抢市场快速上线采用的临时方案← 正确答案
  • B.因程序员偷懒而省略的单元测试
  • C.因预算不足而裁剪的非核心需求
  • D.因领导个人偏好而选定的技术栈

答案:A。战略性技术债务是“明知有利息、依然主动去借”的决策,典型场景是为抢占市场窗口而快速上线,业务收益远大于日后偿还成本。偷懒省略测试属于低质量工程行为,裁剪需求属于范围管理,领导偏好属于组织决策,它们都不具备“战略杠杆”的属性。