为什么使用抽象（例如LINQ）如此禁忌？[关闭]

我是一个独立承包商，因此，我每年要面试3-4次新演出。我现在正处于那个周期之中，尽管我觉得面试进行得很顺利，但还是被拒绝了。今年我发生了两次相同的事情。

现在，我不是一个完美的人，而且我不希望每个组织都适合。就是说，我的平均命中率比平时低，所以我礼貌地向我的最后一个面试官询问一些建设性的反馈意见，他答应了！

根据访问者的说法，最主要的是，我似乎过于倾向于使用抽象（例如LINQ），而不是倾向于较低级别的有机增长算法。

从表面上看，这是有道理的-实际上，这也使其他拒绝也有意义，因为我在那些访谈中也对LINQ感到不满，而且访调员似乎对LINQ并不了解很多（即使他们是.NET）。伙计们）。

因此，现在我要提一个问题：如果我们应该“站在巨人的肩膀上”并使用我们可以使用的抽象（如LINQ），那么为什么有些人认为它是忌讳的呢？如果代码无需花费额外成本即可达到相同的目标，那么将代码“下架”是否有意义？

在我看来，LINQ，即使它是一种抽象，也只是对为实现完全相同的目的而编写的所有相同算法的抽象。只有性能测试可以告诉您您的自定义方法是否更好，但是如果LINQ之类的东西满足要求，为什么首先要编写自己的类呢？

我的意思不是在这里专注于LINQ。我敢肯定，JAVA世界具有可比性，我只是想知道为什么有些人对使用他们自己未编写的抽象的想法感到如此不舒服。

更新

正如Euphoric指出的那样，在Java世界中，没有任何东西可以与LINQ相提并论。 因此，如果您是在.NET堆栈上进行开发，为什么不总是尝试使用它呢？人们是否可能不完全了解它的作用？

我不认为抽象的使用本身是令人反感的。还有其他两种可能的解释。一个是抽象一次或一次都是泄漏的。如果您给人的印象是（正确与否）您不了解潜在的基本面，则可能在面试中反映不佳。

另一种可能的解释是狂热效应。如果您兴奋地谈论LINQ，并在没有使用它并且没有当前计划的公司的采访中反复提到它，那给人的印象是您对使用旧技术会感到不满意甚至不满。它还会给人一种印象，即您对一种产品的热情使您对替代品视而不见。

如果你真的认为你会很乐意在非LINQ店，试图询问他们有什么做用，并相应地调整你的答案。向他们表明，尽管您更喜欢LINQ，但您可以胜任使用任何现有工具的能力。

一些.NET程序员，特别是来自经典VB / ASP或C ++背景的.NET程序员，不喜欢LINQ，MVC和Entity Framework等新功能。

根据我的观察，该组中的前VB员工可能仍会使用数据访问层和其他十多年前编写的代码。他们还将使用诸如“ n-tier”之类的旧流行词，对.NET Framework 2.0之外的任何内容一无所知，也不希望了解任何有关它的内容。

C ++的编写者往往是面向学术的程序员，他们喜欢编写出色的算法，即使这意味着需要重新发明轮子。他们讨厌自己不亲自编写代码的任何事情。其中一些人还喜欢让受访者自卑，尤其是那些传统程度较低的受访者。

在面试时，您可能会遇到这样的组织。但是，您还会遇到一些使用较新方法的人。不要让一些不好的面试让你失望。

微软有很长的历史，一直在推出热门的新技术，然后在未来的5、10或20年内将其遗忘。在某些人看来，LINQ可能看起来像另一个。他们会注意到Microsoft 无法弃用SQL，但是LINQ可能遵循Silverlight。因此，您可能会看到由于经验不足而引起的偏执狂，或者只是那些被现代技术抛在后面并且对它感到不满的人。

如果代码无需花费额外成本即可达到相同的目标，那么将代码“下架”是否有意义？

总会有额外的费用。

现成的东西的学习曲线总是存在的。获取更新（和依赖项）的痛苦始终存在。总是无法拧破胆量。

对于LINQ，只有第一个才真正适用。许多人认为看似“怪异”的代码难以阅读且难以调试。自从问世以来，我从事过的每个专业演奏会都采用类似于sql的语法。LINQ to SQL（和其他数据源）具有许多陷阱和有限的优化选项。

这些是针对第3方工具和LINQ的一般论点。综上所述，LINQ是该死的有用工具，在大多数情况下应首选。哭泣不是在这里发明的，抽象也不应该强烈地支持认知失调。

他们不知道/不会学习LINQ，但是他们“显然”是优秀的开发人员，因此LINQ一定不值得。这是一个常见的陷阱。

您还应该考虑的其他事情是，您对炫酷新技术的热情只会使人们感到不舒服，并且不希望您到处走动。您并不是在“授权”他们，因为知道这些技术的是您自己，而不是他们。即使他们自己没有意识到这一点，他们也可能正在寻找候选人，以加强他们已经投入大量时间的东西。

您想要表现出一种态度，即“无论您在做什么，我都希望帮助您实现它”，而不是在潜台词中说：“您做事的方式可能很糟糕，让我待在身边会证明它。”

我对此的看法（我猜是TBH，因为我们没人能告诉那些面试官在想什么）是，您经常去面试，解释为什么他们应该雇用您来适应他们的团队，他们的工作方式。

您可以成为完美的开发人员，坚如磐石的入门代码神，但是，如果您想做的事情（强调您过分热情地谈论一些很酷的技术专家）就完全没有任何意义，只是告诉他们您，而您不会适合他们想要的东西。如果他们有一个老式的数据访问系统，无论出于何种原因都无法升级，那么他们就不需要忘记了如何维护它的人。如果他们正在开发新产品，而您真的真的想把这个很酷的新技术应用于任何地方，那么很明显，他们将对将来的代码维护和/或人员培训产生很大的影响。

作为一个自由职业者，如果他们雇用一个临时工，这将是一个更大的问题。在现有的代码和实践的范围内，培训和开发新的工作方式并不是一件坏事-您将待很长时间才能使事情变得更好。在自由职业者的帮助下，他们真的没有为您提供想要的东西，您只是在按照他们想要的方式完成工作，而不是做任何其他事情。（不同意-成为永久雇员）

它可能与LINQ本身无关，我拒绝了一位候选人，他提出并解释了用Haskell编写的所有内容要好得多。我们不做Haskell。这同样适用于公司未使用的任何技术，通常，如果您将其称为好产品，这不是问题。当您过于热情和热衷于此时，就会出现问题。

我从那些不使用Linq的人那里听到了一个令人担忧的担忧，这是我要谨记的：“只是因为您看不到实现并不意味着它并不昂贵”。

请阅读以下代码段：

var resultList = inputList.Where(i=>otherInputList.Count(o=>o.Property == i.OtherProperty) > 0);

LINQ在这里发起的挑战。为什么？因为仅仅因为这段代码看起来优美而优雅，并不意味着它并不是效率低下。带有谓词的Count（）评估其可枚举的父元素的每个元素，并对谓词返回true的时间求和。因此，这不仅是N ^ 2（当inputList和otherInputList的基数大致相等时），它也是绝对最坏的情况N ^ 2。输入的EVERY元素遍历otherInputList的EVERY元素。相反，第一步是使用Any（）而不是Count，因为这确实是您想知道的，并且知道答案为“是”时它将立即退出。设置存储不同值的HashSet otherInputListObject.OtherProperty可能也对您有所帮助；访问变为O（1）而不是O（N），最坏情况下的复杂度，而不是二次最佳情况下的复杂度。

因此，我们看到这些好用的优雅方法背后有很高的成本，如果您不知道这些成本是什么，则可以很容易地将O（我的GD）复杂度算法编码为您的潜在雇主的高性能中央文件服务商或下次登陆主门户页面时，可能需要进行调整。执行此操作后解雇您并不会撤消您的工作，但如果他们认为您会这样做，则不会雇用您，这会阻止这样做。因此，为避免这种情况，您必须证明它们是错误的。讨论这些方法的作用（意味着您必须了解自己）及其复杂性，以及如何在有效的时间内（NlogN或更佳的时间）得出答案。

另一个令人担忧的问题是“当您唯一的工具是锤子时”的古老说法。让您自己代替面试官采访这位Linq迷。候选人喜欢Linq，想要使用它，认为这是有史以来最好的事情。似乎候选者如果没有它就无法编写代码，因为给定的每个编程问题都由Linq解决。那么当它不能使用时会发生什么呢？仍然有大量的.NET 2.0代码，如果对其进行升级，则需要对服务器，用户工作站等进行艰苦的升级，所有这些都可以使用您喜欢的扩展方法。作为面试官，我会试图让您证明，您可以编码高效的排序或使用2.0的排序方法，无论我是否同意Linq库和类似的扩展方法都很漂亮甜。不了解要点的面试官甚至不会费心地试图让您对其他事情表现出才华。他们会假设您没有，继续前进。

这个有点长，但是对某人可能有帮助，所以我随它去。

我实际上遇到了类似的情况，上个月接受了20多次采访（电话和面对面交流）。肯定发生了一些无法预料的事情。

不过，我注意到的一件事是，过去五六年来通常是面试周期中心的事情没有得到明确讨论或简短地讨论。诸如OOP分析/设计的基础知识，模式（设计和体系结构均如此），面向更高级/抽象的.net功能（包括lambda或LINQ，泛型，序列化/数据绑定等），甚至通常是热门方法论的热门话题（似乎没人在乎敏捷与瀑布论或敏捷的风味），工具，ORM的选择或首选的协作方式或源代码管理管理。在一些根本没有提到的情况下，几乎在所有情况下显然都没有关系。

在多次采访中以及在无关行业中的各种无关公司中得到关注的是这些路线：

• 对过时/过时的约定和“回到石器时代”的限制的怪异注视。就像在VS2003中开发具有原始限制列表的原始Web应用程序一样，进一步禁止在.net时代内使用显式功能...仿佛这是对现代开发人员能力的真正衡量...记住的能力9年前的范式和局限性因不切实际/任意的约束而进一步恶化。另一个地方是关于定制收藏的话题，大约是前代收藏。另一个地方是我未使用的级联模型的代码示例，因为我没有使用级联构造函数（它们似乎不知道声明时支持属性初始化，这足以满足需要）。

• 即使在技术专注于平台或协议不可知的情况下，也要极端地关注微观和/或配置设置中的特定实现细节（即，重点不是特定于特定实现或特定用法，而是整个过程）重用/重新定位/可扩展性/根据需要集成）。

• 愿意规范/监督/审查代码/以其他方式将工作转移到离岸团队，以及与之相关的非编码技能。

• 产品/平台/模块/等的特定版本的使用。“所以...您使用的是版本1、2和4？但是不是3，是吗？嗯……{用“ no v3 !!!}注释您的简历”。使用程度似乎并不重要；只有你有或没有用过的东西可言，他们所要求的还有具体的事......没有换人似乎算甚至更广泛的应用和功能齐全的竞争产品。

• 更多地关注“您将如何适应我们的团队”而不是“您实际上是否有能力作为软件开发人员”或“您是否具备为公司增值并帮助我们交付高质量产品的技能和经验”产品”，甚至“您是进来破坏商店的危险白痴”。在某些情况下，我的履历仅作为给定的，甚至所谓的“技术屏幕”或技术面试也不只是一项技能评估，而是一项人格评估。即使是相对短期的合同职位，在两个季节发生变化之前，您都会去那里又去了。

• 这次的公司似乎不太关注解决特定的技术问题，启动新的新领域或大型2.0开发项目，或将特定产品推向市场以利用新兴趋势或机遇或通常的大举步伐。 。我至少在15个地方注意到一个重复的主题，即由3-5个开发人员组成的小组，主要是08年市场崩盘的幸存者，他们能够在过去3年左右的时间内开发出一种产品并发现了一些成功或整个公司正在蓬勃发展，并且他们正在雇用新成员来跟上不断增长的功能需求，或解决/克服他们在这些系统中内置的设计缺陷，或者接管上述平台以免费建立起负责“其他项目”的核心团队。

但是...如果我对这项业务了解一件事，那就是它是周期性的。下次我要寻找新的演出时，如果游戏再次发生变化，我将不会感到惊讶。您只需要保持头脑灵活，进行一些积极的倾听，避免在没有必要的情况下做出绝对的声明，但也不要成为狡猾的人，也不要因为一维而脱颖而出（您来自白痴或一个狂热者，既不可取），或者为过好（可以威胁并花费你一演出）。

只需调整您的方法，然后尝试在下一次给出更合理的响应...就可以以几种不同的方式提及您解决问题的方法...但是，即使这是死记硬背，您的行为也好像您实际上是在思考问题，并且当场推理出来。这样看起来似乎比较谦虚，也没有那么令人恐惧或反感。

当然，墨菲定律就是这样，在您停止对“我当前最喜欢的技术人员”充满热情并采取更加平衡/胡须的姿态之后的下一次面试是，如果您发疯了，那将是您的收获。狂热的家伙。;）

我认为您得出的结论是错误的，因为您的样本集太有限了。尽管我看到相当一部分IT商店对“没有在那里发明的东西” ^1表示强烈反感，但他们中没有一家会根据其对技术栈的偏好而取消候选人的资格：他们正确地相信，他们可以教给正确的候选人使用他们自己的图书馆。

我严重怀疑该公司完全禁止使用LINQ。他们更有可能希望您向他们展示自己的技能。

例如，弄清楚您是否知道哈希表的一种方法是要求您在白板上实现原始表。这个简单的练习向审阅者揭示了令人惊讶的关于您的知识的数据量：他立即了解您是否了解哈希码/等式，以及您了解哈希冲突的知识。同时，很难想象有人会在他们的头脑中重新实现哈希表，因为微软在此方面做得很好。许多算法（例如排序和搜索）也是如此：访问者通常想知道您的背景知识是否足以理解低级交互，而不是检查您是否具有.NET库的工作知识。

可以肯定的是，一旦您被雇用为他们的公司工作，他们会坚持要求您使用库实现而不是您自己的实现。但是在面试过程中，他们会将您推向低级代码，以更好地了解您的真实能力。

我认为您对“我在苏格兰看到一头黑牛，所以所有苏格兰牛都是黑牛”类型做了一些疯狂的概括。

如果我接受了您的采访，如果您无法回答我的问题，我会感到失望。

Linq是一个棘手的人，很多人认为它是伏都教，这是不公平的，因为它实际上非常简单，并且更加聪明。

为了扮演魔鬼的拥护者，原因是许多开发人员只是不关心新事物，而是认为必须使用本地（通常是劣等）工具来解决所有问题。使用抽象没有错。地狱，通常没有充分的理由不使用这些抽象。

听起来像您刚刚采访了一个贫穷的开发人员，该开发人员不了解最新信息，并采取了锤子和钉子的方法处理所有问题。这些类型的开发人员对有用的开源工具（例如NUnit或NHibernate或各种IoC容器）一无所知。那些试图通过在数据库中存储大量过程来解决所有问题的人；那些对MVC完全一无所知的人，尽管它已经问世几年了。