科技领域的试金石

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

自从我在 Dev.to 上开始写博客以来，我的主要主题之一就是我们在评估求职者时所采用的（武断的）标准。事实上，这正是我在这个平台上的第一篇博客的主题，之后我也从多个层面探讨过这个问题。但直到我发表了上一篇文章——一篇关于申请 Facebook 的文章——之后，这个问题才真正变得清晰起来（至少在我看来是这样）。

在那篇文章中，我解释说有人告诉我可能会问到关于.call()“和”的问题.apply()。而且，因为我觉得没必要在这个论坛上“维护”自己的形象，所以我还提到我不得不立刻上网搜索这些概念——因为我对它们并不熟悉。

说实话，我从小就开始写代码了。我从事专业编程工作已经将近四分之一世纪了。我主要从事 JavaScript 开发，大概有十年左右的时间。而我专门从事 React 开发，也有五年多了。

尽管我拥有丰富的实践经验，但我对.call()`or`的概念却并不十分熟悉.apply()。查阅相关资料后，我才恍然大悟——因为我在日常工作中根本不用到它们。而且考虑到“现代”JavaScript 的规范，我甚至不确定未来是否还会用到它们。

作为一名 React 开发者，我对 `React` 非常熟悉.bind()。之所以熟悉，是因为我曾经频繁使用它。但那段时期已经过去了。在我目前的开发工作中（这里“目前”指的是过去两三年），我完全没有用过它。坦白说，对我来说，`React`.bind()基本上已经过时了。当我查阅 `React`.call()和`React` 的相关资料时.apply()，我也同样觉得这些概念已经过时了。

你看，我现在都不用了 this。我并不是说它完全没有潜在的用途this。但大多数情况下，如果你总是依赖它this，我真要怀疑你的 JS 开发水平到底有多“现代化”了。如果你不用它，那么、和的this用途就变得极其……少得可怜了。.bind().call().apply()

但这篇文章并非关于.bind()“或.call()”或“或” .apply()。我真的不在乎你是否同意我对它们的看法。事实上，这篇文章根本就不是关于任何特定的语言结构。这篇文章是关于“技术人员”（比如我自己）的傲慢、试金石和口号。

口令

真正了解一个人的能力……很难。我们大多数人也没有时间去深入研究别人的资历。所以我们走捷径。

我不是在指责谁。我也会这样做。我们都这样做。我们建立了一个非正式的俚语列表，用来判断某人是“我们中的一员”还是“他们中的一员”。

换句话说，我们（有意或无意地）创造了一些暗语。我们创造了一些捷径，用来区分真正的开发者和冒牌货。

在当前的 JavaScript 环境中，指示语（shibboleth）的外观/声音是什么样的？以下是一些常见示例：

• 如果一个 JS 开发人员说“类”、“构造函数”或“面向对象编程”时没有表现出应有的嘲讽，那他就是他们中的一员。

• 如果一个 JS 开发人员说“声明式”、“纯函数式”、“不可变”或“函数式编程”，那他就是我们的一份子。
  
  

• 如果一个前端开发人员（几乎使用任何语言）使用制表符，那么他就是他们中的一员。

• 如果他使用空格（而且只缩进两个空格！），那他就是我们的一份子。
  
  

• 如果一个 JS 开发人员使用点表示法引用对象属性，那么他就是他们中的一员。

• 如果一个 JS 开发者不断地将所有对象属性解构为独立变量，那么他就是我们中的一员。
  
  

• 如果一个 JS 开发人员使用function关键字，那么他就是他们中的一员。

• 如果他使用箭头语法，那他就是我们的一份子。
  
  

• 如果一个 JS 开发人员使用.then()/ .catch()，那么他就是他们中的一员。

• 如果他使用async/ ，那他就是我们await的一份子。
  
  

我还可以继续说下去，但我想你已经明白我的意思了。因为我们没有时间去“深入了解”每个人的技能，所以我们只能使用这些简写代号来快速地将开发人员标记为“我们中的一员”或“他们中的一员” 。

这种方法最大的问题在于它过于懒惰，而且常常导致评估结果严重失实。

如果我能完美地发音“shibbólet”，这是否意味着我是犹太人？有可能。但这也可能意味着我成长在一个深受犹太文化影响的环境中。或者，这可能意味着我学习语言，并且能说一口流利的希伯来语。甚至可能意味着我知道你会用这个愚蠢的测试来筛选我，所以我事先学习了“shibbólet”的正确发音。

同样，我们在评价其他程序员时所采用的那些标准也容易出现严重的误判。更重要的是，这些标准也充斥着我们自身的偏见。

我遇到过一些程序员，他们非常喜欢使用async`/` await。这无可厚非。但有时他们对 `/` 的迷恋到了极点，以至于会瞧不起任何使用.then()`/`的人.catch()。或者嘲笑任何使用 ` \ function` 关键字的人。或者看到class你的代码里有 `\` 就窃笑。换句话说，他们把这些概念当作区分水平低下的程序员的标志。但他们真正区分的是：那些写代码方式和他们不一样的人。

石蕊试纸势利眼

试金石与暗语类似，但并不完全相同。暗语更侧重于沟通——我们希望从其他程序员那里听到的概念，以及我们不想听到的概念。

但真正的考验在于你是否掌握了某些技巧。以下是编程环境中典型的考验方式：

一位候选人前来面试，团队安排这位紧张兮兮、满头大汗的候选人站在白板前。然后，他们让他用二叉树编写一个搜索示例代码。这位候选人经验丰富，对许多编程概念也有着扎实的理解。但他从未学习或实现过二叉树。因此，他无法给出令人满意的解决方案。

这时，面试实际上已经结束了。他们或许会出于礼貌再给他45分钟左右的时间继续面试。但房间里那些正在评估候选人的开发人员已经认定这个人是冒牌货。他们知道他是冒牌货，因为他连二叉树都不会！

我的天啊……这家伙也太没胆了吧！他连二叉树的概念都没掌握，凭什么觉得自己有资格写代码？！他不仅应该被取消应聘资格，还应该被砍掉双手，让他永远都别想再碰键盘！我说得对吧？

当然，现实情况截然不同。在我25年的专业编程生涯中，二叉树对我来说，真正“合适的工具”只有一次。我知道二叉树是什么，也大致知道它应该用在什么地方。但如果今天让我搜索二叉树相关的代码，我首先会花几分钟时间在谷歌上搜索，因为我已经有大约15年没写过任何与二叉树相关的代码了。

但本文并非讨论二叉树，而是探讨这样一个事实：我们往往会抓住自己熟悉的某种编程技术，然后将其作为检验标准，排除潜在的候选方案。

掩饰不住的傲慢

这种“试金石”式的测试充满了傲慢。它的逻辑是：你懂这懂那，所以任何自称“真正的”程序员也应该懂这懂那。如果他们不懂呢？那么，无论经验多么丰富，你都无法忽视这样一个事实：这个自称懂编程的人，竟然做不到你轻而易举就能搞定的“事情”。所以很明显……他们的人生一定一团糟！

这时，那些傲慢的人就彻底炸毛了。他们开始喘不过气来，挥舞着手臂，喊道：

但是，但是，但是……如果这个人连二叉树都搞不定，那他显然不是一个知识面广、知识渊博的开发人员！！

相信我，当一个评判标准达到这个程度时，跟他们继续讨论下去就真的没什么意义了。因为到了这个地步，无论这个人拥有多少知识、技能或经验，都无法改变他不会做这件事的事实。你可以跟他们说：“但是……他可是用汇编语言，在一个长周末的时间里，独自一人写完了特斯拉的整个自动驾驶应用程序。”而他们只会说：“但他连二叉树搜索都不会写，所以他显然对自己的工作不够投入！”

你看，一旦有人认定你应该掌握某些特定的编程知识，他们就不会在意你是否能证明你掌握了所有其他知识！他们总会抓住你不懂这部分知识这一点不放——因此，你很差劲。

持这种观点的人会告诉你，期望候选人具备某些技能——比如编写二叉树搜索程序——并没有错。如果他们做不到，那么以此为由淘汰候选人又怎么能说是傲慢呢？但答案其实非常简单：

对于那些依赖试金石的人来说，他们判断什么是“标准”或“非标准”的依据是：他们自己会做吗？如果他们会做，那么他们就会自动认为任何“真正的”开发人员也应该会做。

我换一种方式再说一遍，因为我希望你能真正理解。

当我们用一些标准来检验其他程序员的能力时，我们通常会假设我们自己熟悉的技能是“常识”——任何“真正的”程序员都应该能够做到这一点。而我们则假设我们不熟悉的技能是……深奥的、罕见的、晦涩难懂的。

那些根据你的二叉树技能来评判你的傲慢之徒，要么是因为 A) 他们的环境恰好大量使用二叉树搜索（因此，对他们来说，这已成为一项常见的编码任务），要么是因为 B) 在他们的开发团队中，这被确立为一项神圣的编码测试，他们所有的现有开发人员要么在加入之前就知道如何进行二叉树搜索，要么在它成为他们环境中的“标准”之后很快就学会了。

因果报应是……

如果你自己听不到，那些傲慢的人还在背景里聒噪。他们坐立不安，争论不休：

不管你怎么说，如果有人不精通二叉树搜索，那他就不是真正的程序员！！！

对此，我只想回应如下：

.call()直到几周前，我对二叉树搜索算法还不熟悉.apply()。看来我算不上一个“真正的”程序员。我得先上网查查资料，才能坐下来从头开始写一个二叉树搜索算法。看来这也说明我算不上一个“真正的”程序员。

但我从事这行已经25年了。你真的相信，如果由我来面试，我就想不出一个你肯定猜不到的试金石吗FAIL？你对自己渊博的知识如此自信，确信我绝对难不倒你吗？

如果我能用某个特定的“试金石”难倒你，那么仅仅因为你没能掌握我碰巧让你在白板上演示的那项技巧而被直接淘汰，你会作何感想？