选择无聊技术与创新实践
摘要
文章认为，团队应选择无聊且已被充分理解的技术以确保可靠性，同时可以在开发实践上自由创新，比如TCR（测试&&提交||回滚），这些实践更易于采纳和放弃，没有长期维护负担。
<p class="empty-line" style="height:16px; margin:0px !important;"></p>
<p>知名文章 <a href="https://mcfunley.com/choose-boring-technology" target="_blank">选择无聊技术</a> 列出了使用创新技术的两个问题：</p>
<ol>
<li>新技术中存在太多“未知的未知”，而在无聊技术中，陷阱已经众所周知。</li>
<li>闪亮的技术具有维护负担，这种负担在所有人都对其感到厌倦后仍然长期存在。</li>
</ol>
<p>这两点都归结为一个观点：技术的主要成本在于维护。即使某种技术易于构建，也可能不易于持续运行。我们无法“放弃”关键任务技术。假设我的团队在 <a href="https://julialang.org/" target="_blank">Julia</a> 上构建了一个新服务，两年后决定这是个错误的选择。我们只能要么承担（昂贵的）迁移所有 <del>数据到 Postgres</del> 代码到 Java 的过程，要么承担（昂贵的）继续运行它的过程。无论哪种方式，公司都需要投入资源让工程师持续学习该技术，而不是做其他有用的事情，比如在脑子里挖加密货币。</p>
<p>技术变化缓慢。不像桥梁那样变化缓慢，但仍然相当缓慢。</p>
<p>现在假设在采用 Julia 的同时，我们还决定开始实践 <a href="https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864" target="_blank">测试 && 提交 || 回滚</a>（TCR）。两年后，我们也厌倦了它。要处理这种情况，我们可以简单地……不再做 TCR。没有需要支持的“遗留实践”，放弃一个流程也没有维护负担。采用和放弃实践比采用和放弃技术容易得多。</p>
<p>这意味着，虽然我们在使用的软件上应该保守，但在如何使用软件上我们可以更自由地创新。如果技术得到 <a href="https://mcfunley.com/choose-boring-technology#embrace-boredom" target="_blank">三个创新代币</a>，那么实践就能得到六七个。而且我们可以通过放弃实践来换回这些代币。</p>
<p>（反过来说，社会流程不如技术“稳定”，需要更多工作来维持运行。这就是为什么“工程控制”被认为比行政控制在减少事故方面更有效。）</p>
<h3>选择无聊材料与创新工具</h3>
<p>进一步推进这个论点，我们可以将技术分为两类：“材料”和“工具”。<sup id="fnref:tools"><a class="footnote-ref" href="#fn:tools">1</a></sup> 材料是需要运行来支持业务的任何东西：我们的代码、服务架构、数据 <em>和</em> 数据库引擎等。工具是我们用来制造材料的东西，但材料不依赖它们。编辑器、个人 bash 脚本等。这些分类是模糊的，但归结为“项目失去这个的后果有多严重？”</p>
<p>反过来，由于工具比材料更容易替换，我们可以在工具上更加创新。我怀疑我们在实践中也看到这一点，人们更换临时性物品比更换数据库更快。</p>
<p>（这篇很短，因为我严重高估了自己能写多少内容。）</p>
<hr />
<h2><a href="https://www.aprilcools.club/" target="_blank">April Cools</a></h2>
<p>还有一周！你可以通过 <a href="https://docs.google.com/forms/d/e/1FAIpQLSc6Yt_ZCA_S6EOt-VVtla-uObnzPlSg9x_VOLgiNGN_-AY-kQ/viewform" target="_blank">谷歌表单</a> 提交你的 April Cools，或者如果你想很酷很技术范儿，可以通过 <a href="https://github.com/april-cools/april-cools.github.io/blob/main/_data/projects.yml" target="_blank">GitHub PR</a> 提交。</p>
<div class="footnote">
<hr />
<ol>
<li id="fn:tools">
<p>这与我们将所有软件称为“工具”的方式不同。 <a class="footnote-backref" href="#fnref:tools" title="跳回正文脚注1">↩</a></p>
</li>
</ol>
</div>
查看缓存全文
缓存时间: 2026/05/16 03:39
# 选择乏味的技术，创新实践方法
来源：https://buttondown.com/hillelwayne/archive/choose-boring-technology-and-innovative-practices
著名文章《选择乏味的技术》（https://mcfunley.com/choose-boring-technology）列举了使用创新技术的两个问题：
1. 新技术中存在过多的“未知的未知”，而乏味技术的陷阱早已为人熟知。
2. 炫酷的技术有维护负担，这种负担在所有人对其厌倦之后仍会长期存在。
这两点都归结到一个理念：技术的主要成本在于维护。即使某个技术便于构建，也不一定便于长期运行。我们无法“放弃”关键任务技术。假设我的团队基于 Julia（https://julialang.org/）构建了一个新服务，2年后发现这是个错误选择。我们就会陷入两难：要么（代价高昂地）将所有数据迁移到 Postgres、代码迁移到 Java，要么（代价高昂地）继续维持其运行。无论哪种方式，公司都需要投入资源让工程师保持对该技术的熟悉，而不是去做其他有用的事情，比如在脑子里挖矿。
技术变化缓慢。虽然不像桥梁那样变化缓慢，但依然相当慢。
现在假设在采用 Julia 的同时，我们也决定开始实践 test && commit || revert（https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864）（TCR）。两年后，我们也厌倦了这种做法。要解决这个问题，我们只需……不再使用 TCR 即可。没有需要支持的“遗留实践”，放弃一个流程也没有维护负担。采用和放弃实践要比采用和放弃技术容易得多。
这意味着，虽然我们在所使用的软件上应该保守，但在使用方式上可以更自由地创新。如果我们在技术上有三枚创新令牌（https://mcfunley.com/choose-boring-technology#embrace-boredom），那么在实践上大概有六到七枚。而且我们还可以通过放弃某些实践来收回令牌。
（另一方面，社会流程不如技术“稳定”，维持它们需要更多努力。这就是为什么“工程控制”在减少事故方面被认为比管理控制更有效（https://hillelwayne.com/post/hoc/）的原因。）
### 选择乏味的材料，创新工具
进一步延伸这个论点，我们可以将技术分为两类：“材料”和“工具”。¹（https://buttondown.com/hillelwayne/archive/choose-boring-technology-and-innovative-practices#fn:tools）材料是指为支撑业务而需要运行的一切：我们的代码、服务架构、数据*及*数据库引擎等等。工具则是我们用来制造材料的东西，但材料本身不依赖于它们：编辑器、个人 bash 脚本等。分类界限模糊，但归结为一句话：“如果失去它，对项目的影响有多严重？”
反过来，因为工具比材料更容易替换，所以我们可以对工具更创新。我猜在实际工作中也能看到这一点：人们替换工具的频率高于替换数据库的频率。
（这篇内容比较简短，因为我严重高估了自己关于这个话题能写多少东西。）
---
## April Cools（https://www.aprilcools.club/）
还有一周！你可以通过谷歌表单（https://docs.google.com/forms/d/e/1FAIpQLSc6Yt_ZCA_S6EOt-VVtla-uObnzPlSg9x_VOLgiNGN_-AY-kQ/viewform）提交你的 April Cools，或者如果你想显得更酷更极客，可以通过 GitHub PR（https://github.com/april-cools/april-cools.github.io/blob/main/_data/projects.yml）提交。
相似文章
为变更优化，而非应用性能
本文指出，软件团队常常过度优化微性能基准测试，却牺牲了开发者体验和工程吞吐量，而这两者才是长期交付速度与可维护性的真正瓶颈。
引用 Mitchell Hashimoto 的观点
Mitchell Hashimoto 观察到，大多数技术决策者优先考虑职位安全而非创新，这导致他们倾向于采用安全且流行的解决方案（如 AI 上下文引擎），而不是构建具有防御性的技术。
@dotey: https://x.com/dotey/status/2055097242755706984
资深开发者常因过于强调代码复杂性而无法与业务团队有效沟通，而业务团队真正关心的是消除不确定性。文章建议开发者用“能不能试个更快的办法”来拉通双方案，并指出AI虽能快速写代码，但承担责任的仍是人类。
@djfarrelly: https://x.com/djfarrelly/status/2052779234234380479
本文主张，AI Agent 的开发应基于稳定的执行原语，而非会随新兴编排模式频繁更迭的僵化框架。文章强调，采用持久化步骤、持久状态、并行协调、事件驱动流程以及可观测性设计，可有效避免因最佳实践不断演进而付出的高昂重写代价。
你需要能够降低维护成本的 AI
James Shore 认为，AI 编码代理必须显著降低软件的长期维护成本，才能真正带来生产力的提升，而不仅仅是加快初始代码的编写速度。文章引用了“大众智慧”对维护负担的估算，并警告称，如果不降低这些成本，团队将面临收益递减和技术债务的问题。