他人准则与意向谬误

很多时候，当我阅读别人写的代码，甚至是我自己很久以前写的代码时，我都会陷入一种不知所措的状态，感觉删除或修改现有代码都是不对的。我正在重构的代码已经过测试（希望如此）、经过审查（希望如此），并且在生产环境中运行了很长时间，没有出现任何错误（希望如此），以至于没有人会记得为什么某些代码会这样工作。尽管所有内容都在源代码控制之下（希望如此），但锁定解决方案并且不想删除它是很自然的。毕竟，它是有效的！如果它在生产环境中运行良好，并且是按照某种方式编写的，那么一定有这样编写的原因，即使这个原因对读者来说毫无意义。

对吗？（错）

我花了比我愿意承认的更长的时间才理解这一点，但有很多代码是可以运行的，经过测试，经过审查，但却以那种方式编写，没有任何特别的原因。就像你或我可能会写出以下简洁的代码块一样：

function(x){
    return somethingElse(someOperation(x));
    // this is obviously a contrived example
}

而不是这个更具描述性的块：

function(x){

    var y = someOperation(x);

    var z = somethingElse(y);

    return z;

}

其他人可能会拆分变量声明，或者不必要地将代码拆分成函数，或者在应该拆分函数的时候却没有拆分，因为他们只是想完成工作。我常常因为优先考虑截止日期和目标而不是简洁明了而感到内疚，在某种程度上，我应该感到内疚。但归根结底，稳定、经过测试、可以运行的代码总比“优雅”的代码、干净的代码，或者那些经过反复审核和修改却从未发布的代码要好。此外，尽管我们尝试优化、测试、审核，并且几乎把所有事情都做到极致，但软件开发的某些部分最终还是取决于个人喜好。这可不是家具，我们可能不想回头去修，但如果有必要，我们可以这么做。

当我们不可避免地要回头修复旧代码时会发生什么？正如前文所述，我个人很难删除或重写旧代码。这并不是因为我太懒，也不是因为我看不懂，而是因为我觉得它之所以被这样写是有原因的，是有计划的，而且是由更精通这个问题的人写的。根据我的经验，这种感觉往往是错误的。

我天生喜欢给所有东西起个名字，这让我一直在寻找一个合适的词来描述这种模糊的感觉，这种赋予现有代码超乎寻常的价值和明确意图的感觉。最近，我在一个很棒的播客《No Cartridge 》中找到了它。

我们一直在谈论的这种感觉与文学理论中一个叫做“意图谬误”的概念非常契合。W.K. 维姆萨特和门罗·比尔兹利提出的“意图谬误”是指“作者的意图或意图既不可行，也不可取，无法作为评判文学作品成功与否的标准”。在文学批评的语境中，他们的观点是，作者的意图无法从文本中重建，作品本身就说明了一切，无法通过逆向工程来揭示作者可能试图表达的任何隐藏观点，也无法通过书面作品来省略。此外，他们认为，即使是关于作品的笔记，或作者在作品写作时发表的同期期刊，也只是推断作者意图的次要来源，而作为最终产品的作品始终才是主要来源。文本或许并非完美的媒介，但它却是我们评判作品意图、意义、价值和影响力的唯一媒介。这些理念在代码中或许并不完全相同，但我们能看到一种韵律正在逐渐形成，对吧？

在评估一段代码时，通常无法从代码本身推断出实现细节的意图。也就是说，我们当然可以通过查看数据的起始和结束状态、调用的方法等等来推断作者的意图，但为什么某些事情要以某种方式完成，我们常常会忽略。

注释（如果有的话）可以解释一些“为什么”，但注释往往是在代码短视的阴影下写成的，这种狭隘的视野往往在你长时间埋头苦干某件事以至于忘记了整体目标之后才会出现。它们也可能记录并规范一个根本有缺陷的方法的意图，或者在存在更简单的解决方案的情况下，为一个过度复杂的解决方案提供依据。毕竟，我们编写代码并非总是在完美无缺的条件下，头脑也并非总是清醒的。注释还存在错误传达作者意图的风险，或者在代码更新时注释却没有更新，从而导致下游出现更严重的问题。

文档或许有帮助，但记录实现细节并非良策，因为这会导致文档变得脆弱，需要像代码一样频繁更新。文档最好用来描述一段代码所遵循的契约，而不是解释为什么某些事情要以某种方式完成。答案可能是“凌晨两点，如果我以其他方式执行，就会出现一个奇怪的 bug，我需要把它完成，但我们之后就再也没碰过它了”。这些答案可能不是最佳实践，也不是我们想要达成一致的事情，但我认为任何在生产代码库上工作过的人都见过类似的事情。

如何避免这类问题最好留给经验丰富的开发人员去解决，这方面的文章已经有很多了。我唯一的建议是，始终牢记编写清晰、干净、专注的代码的重要性。我发现Lambda 服务和面向服务架构很有帮助，但没有哪种方法能够真正做到万能。

我更广泛的观点是，代码一旦写好，就只能通过其功能和读者对它的理解来质疑。即使你能联系到原作者，也无法通过任何可靠的方式从作者的意图来质疑它。相信自己，如果经过一番努力后代码仍然无法理解，这并不是对你智力的质疑。这意味着你有机会理解和改进代码库的某个部分。如果它是故意以某种方式编写的，你总会遇到这种限制。那时，你可能有机会克服这种限制，并永久地改进团队的工作成果。你和原作者一样拥有代码库的所有权，如果你被明确要求重构或更新某些特定功能，你可能拥有更大的权力去修改代码。当你这样做的时候，我建议你可以自由地深入研究尽可能多的先前实现。如果你害怕不断地摆弄那些看似不透明的功能，那么克服越来越大的问题将会非常困难。只要记住尝试让代码比刚进来时更清晰，因为有一天有人可能会来问你为什么以某种方式实现某些东西，你可能会意识到很难弄清楚作者的意图😄。

如果您喜欢这篇文章，请随时在 dev.to 上推荐、分享并关注我！

如果你喜欢这个话题，想定期看到类似的内容，或者只是想联系我，请在推特上关注我@dangolant！另外，也要感谢我的推特好友@thejaredwilcurt和@milkstarz 的分享。