老代码库质量扫描怎么绕开历史债，只卡新增代码
建立基线快照，通过版本对比将扫描范围收敛到本次变更引入的问题，历史债单独登记、分期消化，不与新增代码混入质量门禁。基线需版本化并随还债动作滚动更新，规则按阻断型与提示型分级，分别用于CI拦截和趋势管理。
分类: 全栈工程化
共 50 篇文章
前后端各跑各的 lint，最后在 pre-commit 和 CI 里用同一份规则文件把两套工具链对齐
前后端 lint 规则难以对齐的根源在于规则源分散，补救式同步只会持续打补丁。可行方案是建立一份工具无关的规则源文件，由生成器派生出 ESLint、RuboCop 等各自的配置，并在 pre-commit 与 CI 中消费生成产物，通过配置漂移检查保证规则变更原子化。对齐的核心是规则意图而非工具行为，需区分全局一致与语言特有规则。pre-commit 只跑暂存文件的快速检查，CI 负责全量权威验证，两者共享同一份生成配置即可避免规则漂移。
大模型写的代码过了功能测试，但静态检查一跑全是坑——AI 生成代码的安全与规范漏洞该怎么补
AI 代码功能测试易过但静态检查常挂，根源在于模型优化“看起来对”而非工程合规。功能测试覆盖不到安全与规范问题，需将静态检查优先级提升，采用从严规则、专项扫描，并将报错反馈给模型自修。审查者则转向业务逻辑、依赖合理性等工具盲区。
给 SonarQube 质量门禁接 GitHub Actions 时，我按改动频率和修复成本把指标分了三档，豁免规则只留给有记录的例外
三档质量门禁策略：硬性阻断项（重复率、安全热点、可靠性）零豁免；高成本维护项（新增代码覆盖率、重复率、安全热点）必须清零；可延后项仅作 PR 注释提示。豁免规则强制要求带编号记录，杜绝口头跳过。Actions 接入需配置 PR 集成、限定扫描目录、对齐覆盖率产物路径，并避免重复触发扫描。
用 git blame 揪出高频改动模块，再拿静态分析结果交叉比对，重构顺序就不靠拍脑袋了
通过交叉比对 git blame 与静态分析数据，定位“高热高烂”文件作为重构第一优先级。热度反映业务压力，复杂度揭示出错风险，两者结合避免直觉误判。方法包括四象限排序、归因分析、热点方法定位及知识孤岛识别，并强调数据清洗、阈值设定和季度性重复评估，最终输出可执行的重构作战图。
依赖漏洞扫描卡在 PR 合并前，我们靠一道自动门把第三方库更新挡在了 main 外面
依赖漏洞扫描常被忽视，报告滞后导致问题进入 main。团队将 osv-scanner 与 license-checker 嵌入 PR 流程，通过 GitHub Actions 设置高危漏洞和不合规许可证的强制门禁，配合分支保护实现事前拦截。上线后 main 分支漏洞告警归零，月均拦截多个问题 PR，显著降低修复成本。
圈复杂度阈值别拍脑袋定成 10，我们拿三个真实项目的缺陷密度数据倒推出来的基线
圈复杂度阈值设定应基于缺陷数据而非拍脑袋。三个Java项目统计显示，缺陷密度在圈复杂度11–15区间出现超120%的跳变，验证了10作为合理基线。建议分层落地：CI阻断阈值20，代码审查触发阈值10，存量代码分开治理。同时结合嵌套深度和认知复杂度指标提升准确性，并注意不同语言需重新校准阈值。
开启 TS 严格模式时，让 CI 只对新改动做增量检查，历史错误先挂账不爆仓
在 CI 中对 git diff 结果运行 tsc --strict，实现新代码从第一天起严格模式，历史错误通过 @ts-expect-error 挂账清单管理。方案包括：用 tsconfig.strict.json 覆盖主配置、仅对增量文件检查、生成欠账报告、处理依赖闭包误报、配合 ESLint 规则，以及按模块推进销账。已在两个存量项目验证，有效阻止新隐式 any 和空值风险，同时不阻塞 CI。
从 Git Flow 切到 Trunk-Based Development，我们的分支策略迁移步骤和 CI 流水线改造实录
从 Git Flow 切换到 Trunk-Based Development 后，发布周期由 11 天缩短至 2.3 天，hotfix 流程大幅简化。文章详述了分支规则、Feature Flag 管理、CI 流水线改造及迁移步骤，并分享了踩坑经验与效果数据。
给同一个 ESLint 配置按目录分层，我们用 overrides 把规则冲突压下去了
一套 ESLint 规则难以适配所有目录，`overrides` 是分层治理的关键。建议顶层设最严基线，再按目录逐层放宽，如测试目录允许 `any`、脚本目录放开 `console`。注意 `files` 需用 `**` 匹配多级路径，多个条目冲突时后者覆盖前者。`overrides` 还能换 parser、细化规则参数，并可通过拆分配置片段避免主文件膨胀。