Chesterton的中指

# Chesterton的中指 来源：https://www.arp242.net/chestersons-finger.html Chesterton的栅栏（https://fs.blog/chestertons-fence/）这个比喻告诉我们，改变你不理解其存在原因的事物时要谨慎，因为可能有你尚未考虑到的合理缘由。这在不同场景下都是很好的建议，包括编程领域——我们很容易“修复”一些奇怪的代码，结果后来出现问题才发现那些奇怪写法自有道理。 这就是Chesterton的中指： `` # 列出所有提交正文（不包括标题行） % git log --no-merges --format=format:'%b' | sed '/^$/d' | wc -l 295 `` 过去13年里，总共有295行提交正文文本。提交标题通常只是一句“修复页面A”——甚至对于重大改动也是如此——毫无意义。如果手动移除一些dependabot的提交、“回滚提交”和“修正错别字”的提交正文，只剩167行。大概每月一行。 没有其他文档。代码里几乎没有任何注释。 这就是Chesterton的中指：“是的，我们做了所有这些奇怪的事，但不告诉任何人为什么。哈哈，去你的。” 这不是我第一次看到毫无用处的提交日志，但却是第一次在所有人都离职后才被雇来接手。没有人可以询问。 理论上，前任开发者有三周的交接期，但那个交接和提交日志一样缺乏沟通。我从未如此同情杰克·鲍尔（Jack Bauer）逼供信息的方法，并遗憾没有采用其中一些。 有未完成的重构。有已移除功能留下的残留代码。有添加但从未链接/使用的功能。有似乎无人使用的功能。总体上，它似乎严重遭受了Chesterton的空隙（https://stephantul.github.io/blog/unfence/）（“还没有栅栏？我们建个栅栏吧！”——却不问问是否真的需要栅栏）的困扰。 一切都只是一根大写的中指。 --- *写得好*很难。写得勉强过得去却不难。大致要回答三个问题：“你在改什么？”“为什么改？”“为什么这是个好方案？” 有时候“实现新功能X”就够了，但很少有情况是没什么可补充的——大多数时候，关于如何以及为何以当前方式添加功能，总有些东西可以说。 如果你在修复bug、重构或修改东西，或者进行其他实质性改动，那么极少会写不出一两句关于“改什么、为什么改、为什么好”的评论。 写这些并非额外可选的任务；这是工作的一部分。如果你不做，你就没有尽到软件开发者职责。不需要文采斐然。不需要完美的英语。不需要写成关于现实本质的全面论文。忘记点什么也没关系（尽管最好不忘）。只需要……*有点内容*。任何半认真的尝试都比*完全没有*要好无数倍。 如果你*什么都不写*，那你就是在给所有后来者竖中指。