语言不可知论之道

许多公司都吹嘘自己在招聘过程中对技术一无所知。这是有道理的，为什么要限制你的候选人人才库呢？他们可能会说：“优秀的开发人员应该能够迅速发现不同语言之间的细微差别，他们的算法知识和经验正是我们要寻找的。”我最近从一个语言不可知的招聘经理，到一个语言不可知的候选人，再到一个语言不可知的家族，再到新手Python开发人员。这是一个非常有趣的过程，我想分享一下旅途中每个部分的一些见解。

在我的上一个角色中，我深度参与了招聘过程。我在一家Clojure商店，这是一种小型但不断增长的Lisp方言，可编译成JVM。由于很难找到听说过Clojure的开发人员，更不用说编写产品代码了，所以我们寻找具有任何语言背景的优秀开发人员。我们还在前端编写ClojureScript，所以即使是JavaScript开发人员也是从头开始。

在一次采访中，在我们解决了我给他们的任何建模或算法问题之后，我确保注意到如果我们使用Clojure可以解决问题的方法。对我的笔记有三种不同类型的反应。一些应聘者会点头或说这很有趣。其他人会对这种做法提出质疑，或者为自己的母语为什么会这样做而辩护。最后一组会询问更多关于Clojure的特性和决策，甚至推断某些特性可以用于其他问题的方式。当然，我最喜欢这些候选人。

可能很清楚的是，候选人以前拥有的知识可能是他们编写Clojure代码成功程度的最差指标之一。最成功的开发人员会接受Clojure思维模式，并深入研究它的特性和特性。迁移困难的开发人员会不断地用他们的母语思考问题，然后尝试将该解决方案转换成Clojure。

这也是一个让我难堪的错误。当我第一次学习姜戈时，ORM对我来说是一个谜。我想做一些看似简单的查询，这些查询我可以很容易地用SQL编写，但我终究搞不懂如何使用ORM来做这件事。我想，很简单，我将首先编写SQL查询，然后将其转换为ORM查询。我找到了一本关于SQL到ORM转换的指南，但它没有帮助。我需要接受ORM的思维方式。我必须开始以ORM的方式思考，而不是转换SQL查询。一旦我接受了ORM，它就是一个强大的工具，可以帮助我快速探索数据并编写更优化的查询。

在采用新堆栈时，工具是另一个需要做出的决定。您是坚持使用您所知道的知识，还是使用特定语言中更常见的工具。我最熟悉的是IntelliJ作为我的主要IDE。幸运的是，JetBrains还开发了流行的Python IDE PyCharm。我决定坚持使用IntelliJ，很多功能在两个环境中都是相同的。我还学习了很多其他工具，所以熟悉IDE很重要。其他工具和环境变化包括：AWS->；gcp、OS X->；Ubuntu和Sequel Pro->；pgAdmin III。

我们将为您做出其中一些选择。Sequel Pro仅适用于OS X，不支持PostgreSQL。我被迫换了一个新客户。很多其他开发人员会使用CLI客户端，这是我从来不喜欢的。我很高兴接受新工具，但失去一些使用GUI的开发人员身份似乎太遥远了。幸运的是，我找到了pgAdmin，它的功能与Sequel Pro非常相似。我甚至开始使用Sequel Pro中没有的一些功能，比如便签簿，因为我愿意探索新工具提供的一切。

在学习新的代码库时，重要的是要理解在设计它时所做的决定。当创建不同的模型时，人们首先想到的是什么。已经犯了哪些错误，代码已经经历了哪些重构。需要了解的另一个重要方面是代码库的未来计划是什么。应用程序的哪些领域仍然需要重构？在我们可以构建某个功能之前，需要实现哪些技术？这些问题中的大多数不能由代码本身来回答，它不能在StackOverflow问题上找到，甚至在库文档中也找不到。这些信息存在于构建和维护代码库的开发人员的脑海中，如果您真的很幸运的话，还有他们编写的关于他们选择的文档。

在我在Remesh工作的头几个月里，我真的很兴奋能为我一直在制作的一部中等大小的特写做公关。我会要求评论，然后看到评论和更改请求蜂拥而至。我不想撒谎，很多早期的代码评审都很粗糙。不是因为我做错了事情，有时候是的，而是因为我没有意识到很多已经做出的决定。我不知道其他开发人员为了使代码库更有凝聚力和更容易理解而理所当然地试图遵循的约定。

其中一些更改很小，但其他更改需要大量重写。如果我在开始编码之前让几个工程师通过我提议的实现，他们可能会提出一些不适合公司编码风格的方法。事前做一次快速复习会在事后为我节省大量的时间。这就是为什么我极力推动在Remesh实施正式的审查流程，以避免其他开发人员遇到我所面临的问题。

设计评审是记录所有这些选择并确保它们与其他开发人员正在做出的决策一致的好方法。我们的设计评审结构相当简单。快速总结您正在尝试解决的问题，然后列出您考虑过的所有解决方案以及您希望实施的解决方案。

比较权衡会更好地框定问题。审查者能够快速查看建议的解决方案，并评论为什么他们更喜欢一种解决方案而不是另一种解决方案。查看设计者没有选择的解决方案可以更好地洞察设计者试图解决的问题。通常，真正的问题是通过选择的解决方案来发现的，或者为什么看似简单的问题会有如此复杂的解决方案。

设计审查是头等大事。虽然它们可以通过防止需要彻底重构的糟糕设计来极大地提高性能，但编写文档的工作很多，可能只会被同行快速审阅。列出实现如何工作的具体细节可能是不必要的步骤。很多时候，这类决策最好以代码的形式进行交流。考虑的是什么？为什么某些解决方案效果不佳？此问题与其他似乎与此问题类似的问题有何不同？这些是设计评审应该回答的问题类型。

它为未来创造了清晰的模式。剥猫皮的方法有很多种，优秀的工程组织以类似的方式解决问题，这样他们就可以很容易地被组织的其他人理解并与之沟通。这允许多个开发人员处理代码库的许多部分，因为他们知道代码库将是熟悉的，并遵循特定的模式。设计评审有助于限制图案的数量。除非问题确实需要唯一的解决方案，否则我们更喜欢使用我们以前使用过的模式。设计评审记录了这些模式，并提供了一个很好的模式列表以供选择。

学习一个新的代码库是困难的，在此基础上学习一门新的语言就更难了。遵循上述规则：

使用设计评审可以及早澄清问题，并防止在代码评审之后进行大规模重写。