写代码现在很便宜

Source: Hacker News

采用代理式工程实践的最大挑战在于接受这样一个事实的后果：编写代码现在已经很便宜。

代码一直都是昂贵的。要产出几百行干净、经过测试的代码，往往需要大多数软件开发者整整一天甚至更久。我们许多工程习惯——无论是宏观层面还是微观层面——都是围绕这一核心约束构建的。

在宏观层面，我们花大量时间设计、估算和规划项目，以确保我们昂贵的编码时间能够尽可能高效地使用。产品功能的想法会以它们能在花费的时间上换取多少价值来评估——一个功能必须多次抵消其开发成本才算值得！

在微观层面，我们每天会基于可用时间和预期权衡做出数百个决定。是否应该重构那个函数让它稍微更优雅，即使这会额外增加一小时的编码时间？写文档呢？为这个边缘情况添加测试值得吗？我能否为此构建一个调试界面？

编码代理大幅降低了在电脑上敲代码的成本，这颠覆了我们许多关于哪些权衡是合理的个人和组织直觉。

并行运行多个代理的能力让评估更加困难，因为现在一个人类工程师可以同时在多个地方实现、重构、测试和编写文档。

好代码仍有代价

交付新代码的成本已经降到几乎免费……但交付好代码仍然要贵得多。

以下是我所说的“好代码”的含义：

• 代码能够正常工作。它按预期执行，没有 bug。
• 我们知道代码能工作。我们已经采取措施，向自己和他人确认代码符合预期用途。
• 它解决了正确的问题。
• 它能够优雅且可预测地处理错误情况：不仅仅考虑理想路径。错误信息应提供足够的细节，以帮助后续维护者了解出错原因。
• 它简洁且最小化——只做必要的事，以一种人和机器现在都能理解、未来也能维护的方式实现。
• 它有测试保障。测试表明代码当前可工作，并作为回归测试套件，防止将来悄然出错。
• 它有适当层级的文档，且文档反映系统的当前状态——如果代码改变了已有行为，文档也必须相应更新。
• 设计考虑未来的变更。保持 YAGNI 很重要——为可能永远不会出现的未来变化而增加复杂度的代码往往是糟糕的——但同样重要的是不要写出让未来变更比必要更困难的代码。
• 以及所有其他相关的“‑性”——可访问性、可测试性、可靠性、安全性、可维护性、可观测性、可伸缩性、可用性——这些非功能性质量度量适用于所开发的特定软件类别。

编码代理工具可以帮助完成其中的大部分工作，但仍然需要使用这些工具的开发者承担大量责任，以确保生成的代码在当前项目所需的良好子集范围内是好代码。

我们需要培养新习惯

挑战在于发展能够响应代理工程的可用性和机遇的个人和组织新习惯。

这些最佳实践仍在整个行业中探索中。我自己也在摸索中。

目前，我认为我们能做到的最好方式是自我反省：每当直觉告诉我们“别做那个，花不值得时间”，仍然在异步代理会话中发送提示，最坏的结果也只是十分钟后检查时发现它并不值得消耗代币。