5 posts
Literate programming 承诺单一事实来源，但手动的 weave 和 tangle 步骤会破坏 CI/CD 流水线。以下是如何自动化提取和文档生成，使 Markdown 文件保持规范。
如果你的构建流水线必须等你打开终端输入 才能运行，那你就没有文学化程序。你有的只是一本绑着编译器的日记。 文学化编程的全部意义在于散文和代码共享单一事实来源。Markdown 文件就是产物。其他一切——可执行源码、渲染后的文档、测试文件——都是派生的。派生产物属于 CI，不属于你的工作记忆。 问题不是 CI 能不能…
大多数团队把架构规则写在维基里。这里介绍如何把它们写成可执行的测试，当你的依赖图发生漂移时让 CI 挂掉。
你的测试套件验证了 在输入正确时返回 42。但它没有验证 是否被允许导入 。编译器对两者都满意。你的单元测试对两者都满意。但其中之一是架构违规，六个月后会让你花上一周时间来重构。 这就是盲区。我们为逻辑写测试，却假设结构会自行管好。并不会。…
整洁架构的图在白板上看着很美。本文介绍如何在构建流水线中强制执行依赖方向，让领域代码永远无法触及基础设施。
团队里有人刚在 里引入了 。PR 编译通过。测试全绿。代码审查长达三百行，却没人发现。 三个月后，你想把领域逻辑抽成一个共享包。做不到。它依赖了 Postgres 的类型、连接池逻辑，以及一个只在单体应用里存在的自定义驱动封装。白板上那套同心圆架构图，此刻成了笑话。 这就是没有自动化 enforcement…
大多数团队不会每次提交都跑完整的变异测试套件。以下是工程团队如何在不破坏构建流水线的情况下，真正把变异测试集成进CI的做法。
如果你的变异测试套件需要跑四个小时，恭喜你。你证实了大家早就怀疑的一件事：你的测试套件存在漏洞。 你不可能每次 push 都到 CI 里跑这个。没有哪个团队会这么干。问题不在于你能否承受每次提交花四小时，而在于你能否承受带着“测试通过但实际上什么也没验证”的代码上线。…
人工审查不一致，AI 审查更不可靠。AI 生成 codebase 唯一可扩展的防线是确定性 enforcement：让构建失败的规则，而非被忽视的建议。
对 AI 生成代码的标准建议是"仔细审查"。 这个建议正确但在规模化时毫无用处。 开发者审查 AI 输出时，在精力充沛、熟悉领域且没有时间压力的情况下能发现问题。在其他所有条件下——而这是大多数情况——问题会漏过。 用 AI 审查者来发现 AI…