你好 👋
是因为你提出了一个关于如何改进 Exercism 的想法，然后有人把你引到了这篇文章吗？
在我们团队花时间研究你的想法之前，希望大家先读一读这篇，想一想：你的想法以前是不是已经有人提过，它又可能包含哪些坑。
如果你在建议里一并考虑到这些情况以及潜在的坑，并想一想你的想法为什么可能还没有被实现，通常就能得到更快、更积极的回应。
那么，“切斯特顿的栅栏”到底是什么意思？
切斯特顿的栅栏这个说法，源自作家 G.K. Chesterton 在 1929 年出版的书 The Thing 里的一句话。
它因为被约翰·F·肯尼迪引用而广为人知。
以下是原文：
在这种情况下，总会存在某种制度或法律；为简单起见，我们就把它说成是横在道路上的一道栅栏或一扇门。
比较新派的改革者会兴高采烈地走到它跟前，说：“我看不出它有什么用；咱们把它拆掉吧。”
更聪明的改革者则会这样回答：“既然你看不出它有什么用，我当然不会让你把它拆掉。回去好好想想。等你哪天回来告诉我你能看出它有什么用了，我或许会让你把它拆掉。”
切斯特顿的栅栏想要表达的是：如果你不明白某样东西为什么会在那里，那你大概也就不明白它为什么应该被拿掉。
同样的道理，如果你不明白某样东西为什么不在那里，那你大概也就不明白它为什么被漏掉了。
可以记住一条简单的规则：“在你弄清一道栅栏最初为什么被立起来之前，别把它拆掉。”
这个观念和 Exercism 有什么关系？
在 Exercism，我们很幸运，一直有大量的人加入我们的社区，分享他们的想法和点子。
其中很多点子很新、很有创意、让人兴奋，还能帮我们打开思路。
所以，如果你有想法或建议，我们都很欢迎！
不过，更常见的情况是，人们提出的想法其实已经被讨论过很多次了。
回应这些想法、重新处理或重新解释我们的决定，会极其耗费团队的精力。
这篇文章的目的，就是帮忙守住这些时间和精力。
Exercism 由成千上万位非常有才华的人设计、开发和构建而成。
它是一个非常刻意的产品：有些东西在那里，是因为它们被设计成要在那里；有些东西常常被省略，也是因为它们被设计成要被省略。
Exercism 上几乎所有的东西都经历过反复的争论、讨论和重新设计。
所以在发表你的想法之前，请先问问自己：我们是不是可能已经考虑过它了？我们又为什么可能和你建议的做法不一样？
而且要记住：你的想法看起来越显而易见，它就越可能已经被反复讨论和争论过。所以当你提出它时，也请把可能需要注意的地方和坑一起写出来。
如果你下意识想说“为什么不直接……”，那它几乎肯定就属于这一类。
千万别害怕发帖，但请先认真想清楚！
有例子吗？
一个常见的烦恼是，学员会把没通过测试的代码提交给导师。
同样常见的建议是：“为什么不让 CLI 在提交代码之前自动运行测试？”
这看起来是个很棒的主意：CLI 只要调用一个命令来运行测试，如果测试没通过，就不让学员提交。
那首先，“只要调用一个命令来运行测试”意味着什么？
它意味着要为 Exercism 上的 52 种语言各写一个脚本，能运行测试并检查结果。
这要花点功夫，但还做得到。
但这还意味着，这个脚本得能在 Windows、MacOSX 和 Linux 上运行，而且要覆盖所有可能存在的版本和配置。这个工作量非常大，甚至可以说是无穷无尽的。
你可能会问：“为什么非要覆盖_每一种_配置？”
因为只要有人跑不了这个脚本，你就等于在主动拦着他使用 Exercism。
这也就意味着它绝不能出错。
如果因为某种原因脚本没能运行，那学员就被彻底挡住了。
这些52*3*n个脚本里只要有一个 bug，学员在那台操作系统上就再也用不了那条学习轨道了。
这种情况你要怎么测试？
根本没法测。
可你可能会说，直接加一个--skip-tests参数不就行了。
这是个好建议，但它又把我们带回了起点：人们随时都可以选择绕过测试。
只不过现在的情况变成了：没通过测试的代码被提交的可能性稍微低了一点，导师对此的预期也就降低了，结果当测试真的没通过时，反而更让人错愕和困惑。
你也许会说：“但一般来说大家不会这么干。”确实，对于跑一遍测试只要 0.5 秒的某些语言来说是这样。
但对于跑一遍测试要 20 秒的语言来说，提交前还得多等 20 秒，会让学员烦躁得不行，于是跳过最后这次测试就成了家常便饭。
不管这场讨论最后走向哪里，有一点很清楚：这里牵扯到的复杂度远比一开始看上去要多。有技术上的挑战要考虑，有工作流上的问题要想，还要意识到各条学习轨道之间的差异之大，以至于对一条来说又快又简单的事，对另一条可能就很痛苦。
所以，与其抛出“为什么不在提交之前先运行测试”这样的建议，不如换个问题来问：“为什么有人会提交没通过测试的解答？”
这样一想，事情就有意思了。
一般的原因是：他们卡住了，或者糊涂了。
他们需要帮助。
也就是说，提交没通过测试的代码，对导师来说是一个很重要的判断线索：这位学员_需要帮助_。
没错，这很让人头疼，因为导师没法立刻知道代码到底“对”不对。不过，导师可以下载代码并运行它来验证（对不那么简单的解答，大多数导师都会这么做），然后就能 100% 确定它到底对不对。
而那些卡住、需要帮助的学员，也不会变得更卡、更需要帮助，反而能更快地找到能看出问题并提出修改建议的导师。
注：我们其实正在通过把测试放到服务端运行来解决这个问题：这是一项庞大而昂贵的工程，但为了改善学员体验，特别是为了给导师省下时间和精力，这份努力是值得的。
还有别的吗？
三件事：
-
Second Order Thinking 上的这篇文章值得一读。“在你弄清一道栅栏最初为什么被立起来之前，别把它拆掉”这句话就出自这篇文章。
- G.K. Chesterton 的 The Thing 可以在这里找到：https://archive.org/details/G.K.ChestertonTheThing。
- 你的想法也许真的很新、很棒。别害怕，也别不好意思提出来！
