为什么使用抽象(例如LINQ)如此禁忌?[关闭]


60

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

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

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

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

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

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

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

更新

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


8
我认为您不知道“抽象”是什么,因为LINQ与它无关。
欣快的2012年

8
“我确信JAVA世界具有可比的东西”实际上,LINQ是.NET和Java所没有的少数东西之一。
欣快的2012年

42
@Euphoric-LINQ是否不会抽象掉诸如排序和过滤之类的较低级别的任务?我非常确定,objectCollection.Where(oc=>oc.price > 100)例如,后面会有一些额外的代码。那不是使用抽象吗?也许你可以告诉我我在这里想念的东西。。。
马特·卡察特

37
他们总是有可能不了解 LINQ,也看不到学习它的价值。编写它的功能方面与命令式编程非常不同。作为承包商,我最近在2009年见过“高级” Java开发人员,他们对SQL的理解不足以编写高级查询,因此他们花了数周的时间优化代码,以将所有数据带到Java端并使用Java代码对其进行过滤,而不是数据库这样做。无知在软件开发行业中十分猖ramp。

18
如果您了解LINQ,但您的面试官却不了解,那么您会比他们强。放高眼光。
杰伊·巴祖兹

Answers:


74

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

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

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


4
@MatthewPatrickCashatt您不能在包含linq语句的方法中的调试器中进行编辑和继续。我不使用它是不够的。但这是我犹豫了一段时间的主要原因。
丹·尼利

3
+1,尤其是第二段。它完全适用于我,因为我会完全不悦地在C#代码工作,而能够使用LINQ。
阿森尼·穆尔琴科(Arseni Mourzenko)2012年

5
还有一个事实是,除了泄漏的抽象外,还会经常对性能造成影响。您正在将易用性换为精度,而精度的损失经常包括会使事情变得更快的细节。而且,您与源头的距离越远,散布的细节越多,这些细节对性能的重要性就越大。
jmoreno 2012年

6
+1,但也可以采用其他方式。如果有人告诉我他们没有雇用我,是因为我使用Yacc来构建解析器而不是自己动手,那么那不是我想工作的地方。
Spencer Rathbun 2012年

5
@MatthewPatrickCashatt:这个答案(以及我对此的评论)不是特定于LINQ,而是一般性声明。但是对于LINQ,这是 C#4.0 / 5.0的摘录,内容涉及LINQ的性能问题。回到一般性:在很多情况下,性能下降是值得的,5%+/-是无关紧要的。但是有时它会更大,有时甚至只有0.1%是不可接受的。如果你觉得没有能永远是一个问题,或者说表现是只为谷歌等公司....
jmoreno

29

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

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

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

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


2
谢谢jfrankcarr。我怀疑情况可能是这样-关于开放和关闭存在疑问datareaders
马特·卡萨特

2
+1称MVC为“新东西”。让我大笑。 它是 70年代以来一直围绕。您可能已经说过MVVM,它本质上是使用绑定的MVP(MVC变体)。

14
@ GlenH7我认为从上下文可以明显看出他的意思是产品“ ASP.NET MVC”,而不是Model-View-Controller的基本概念。
Carson63000

4
@ GlenH7-我的发言完全是在.NET和Visual Studio产品线以及Microsoft产品流行语的上下文中进行的。
jfrankcarr 2012年

6
天哪,真的有商店认为Linq是“新”的吗?它已经存在超过4年了。我可以理解没有赶上任务等待者,或者不使用dynamic/ ExpandoObject/ etc。,或者不关心Azure和所有其他云技术……我什至可以理解继续使用老式的WebForms视图MVC或Web Forms本身的Java引擎,或者在没有MVVM的情况下编写WPF / WinRT代码...但是Linq?如果您还没有弄清楚,那么该是时候辞职了.NET开发人员的工作了。
2012年

16

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


12
老实说,虽然我看到了基本要点,但我认为Linq不会很快消失。Linq2SQL,是的,他们不赞成使用它,而推荐使用功能更强大的EF。但是Linq本身是最近3个.NET版本中其他许多闪亮新内容的基础,因此,如果它们不赞成使用,则它们将撤消一半的新持久层技术(例如Azure和EF),更不用说几乎破坏了每个ORM在那里,还有很多内存列表处理。
KeithS 2012年

6
等待...“害怕脱离旧的,过时的技术,因为它可以工作”……WTF。我们是否到了这样的地步:经过尝试,测试,可理解和可维护且成熟的工作内容不好。
gbjbaanb 2012年

7
@gbjbaanb-不 但是-作为轶事-您想让医生通过胸部X光检查诊断您的胸痛是因为该方法是“经过尝试,测试,可以理解的”,还是您想要一种功能较新但功能更高分辨率的fMRI ,更好的预后和更多信息?这里没有人说要放弃经典原则。恰恰相反。您会看到,LINQ(作为示例)是基于这些原理构建的。我认为,正如其他人所提到的,正是对LINQ零件的学习和对LINQ的正确使用导致了诸如您这样的“ WTF”时刻。
Matt Cashatt

2
@MatthewPatrickCashatt:取决于,如果医生没有接受过阅读fMRI结果的训练,我会进行X射线检查,而不是让他猜测诊断结果。如果我在死水中生病,我宁愿有一位医生可以用听诊器诊断,而不用没有最新的终极工具就无法应对。
gbjbaanb 2012年

2
@MatthewPatrickCashatt我明白您的意思,但是一个平衡因素是,您不希望仅因为它是新趋势而遵循所有趋势。我会很高兴地遵循一种适用于以下两种类别的新技术。1.它使我兴奋,我愿意花我的空闲时间。2.它证明自己实际上更好,并且似乎可以持续足够长的时间,使其值得投资。不属于这两个类别之一的趋势充其量是一场赌博。
TimothyAWiseman

15

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

总会有额外的费用。

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

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

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

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


1
好点。同意您提到的费用,这是一个很好的说明。但是,更广泛地说,开发新员工无法熟悉的本地化班级,因为他们不在组织外部,因此除了初级开发的成本外,还面临着相同的挑战。
马特·卡萨特

2
@MatthewPatrickCashatt-绝对正确。因此,为了获得相同的胜利,这种本地编写的代码几乎总是应该花更多的精力,但不一定。像许多其他的东西,成本/收益,应当估计和最佳实践首选,而不是盲目跟进。
Telastyn 2012年

@Telastyn本地编写的代码也很不错,因为您知道它的作用并且可以立即对其进行修复。此外,您可以根据自己的使用情况(而不是每个人的平均值)针对特定情况进行优化。
霍肯2012年

13

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

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


+1 -以及告诉他们,你知道些什么,问他们什么他们正在做什么他们专门英寸
柯克布罗德赫斯特

12

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

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

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

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


2
我同意这一点,但是我注意到更多的人使用这种态度来抛弃他们只是不理解的主意(例如测试,设计模式,ORM)。因此,尽管我同意适合团队工作是一件好事,但重要的是要意识到自己可能比团队中的其他成员更好,并且应该找到志趣相投的人,知道好事并不是一件坏事抽象。
韦恩·莫利纳

1
@WayneM可以肯定,但是OP是一名自由职业者,因此,如果他是一名编码神真的不重要,除非他们准备永久雇用他来维护编码,而团队的其他成员则不了解(嗯)他需要做他们想要的,而不是他想要的。
gbjbaanb 2012年

1
@WayneM同样,很多人会使用与您刚才说的类似的东西来宣传他们的想法超过别人的想法(确信与他们交谈的人根本无法理解)。最终,双方都有偏见,但OP即将被录用,而不是赢得巨大的DIY /抽象战争。每个人都有自己的见解,但必须克服。我猜在这种情况下不会成为雇主。:(
霍肯2012年

10

我从那些不使用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库和类似的扩展方法都很漂亮甜。不了解要点的面试官甚至不会费心地试图让您对其他事情表现出才华。他们会假设您没有,继续前进。


您为什么不只将查询写为var resultList = inputList.Select(i=>i.Property).Intersect(otherInputList.Select(o=>o.Property));?我可能对此感到很拙劣,但我的观点是LINQ有更好的方法来执行您上面提到的查询(.Join()是另一种方法)。我意识到,使用LINQ的方法可能不如其他方法精通,但这并不意味着您必须依靠那些不良的实现。
马特·卡萨特

4
@MatthewPatrickCashatt我认为LINQ总是效率低下,我认为他的观点不是那么重要-尽管您总是可以击败给定的LINQ查询,但某些用法每开发人员小时的性能要比许多非LINQ方法更好。相反,它可以比较容易写一个LINQ查询效率低下,没有意识到这一点,因为低效率是不是明目张胆。
乔恩·汉娜

3
@JonHanna:也许更重要的是,如果必须检查“真正在做什么”的代码来确定哪些不常见但可行的方案可能导致性能比预期差许多数量级,那么抽象的价值就会大大降低。如果从一种数据结构更改为另一种数据结构会使代码运行慢10,000倍,那么在不更改任何其他代码的情况下进行此类更改的功能可能并不总是一件好事。
2012年

1
@supercat:是和否。仅仅因为了解如何在第三方实现中完成某件事对于理解性能影响和避免效率低下至关重要,但这并不意味着封装这些工具的库的价值降低。这是同一枚硬币的两个面;知道实现的本质,您可以通过几次击键来使用它,而不用花一个小时滚动自己的代码。但是,您必须了解双方,以及刻板印象的Linq狂热者,他们认为这是完美的,没有错,可以将其用于可能没有的所有事情。
KeithS 2012年

@KeithS:我认为Java和.net都非常缺少的一件事是一种询问对象或集合有关自身的各种事物的标准方法。例如,接收可枚举集合的代码可能会受益于知道项目的数量和/或现有项目的顺序是否可能发生变化,知道项目的数量是有限的还是无限的(或者两种方式都不知道),以及该收藏集是否固有地知道其中包含多少项。像LINQ这样的技术通常必须对可能正确或不正确的事情做出假设,而且……
supercat 2012年

10

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

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

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

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

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

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

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

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

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

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

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

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

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


6

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

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

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

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


1一个店去就建立自己的比较原始的构建工具!


2
您的所有观点都做得很好,但是在上一次面试时我应该给您一些色彩:面试官坚持认为LINQ已被“弃用”。我问:“你不是说微软将不再在Linq-to-SQL上进行投资,而是Linq-to-Entities将会出现。”他的回答是他的意思是他说的:LINQ被“弃用了”因此,不,我认为他对LINQ不太了解,或者会坚持使用它。
马特·卡察特

1
@MatthewPatrickCashatt如果有人因为不赞成使用的技术而对LINQ与LINQ2SQL感到困惑,那么我会以愚蠢的借口提早离开面试,并且从不回电话。如果确实如此,您应该为他们不雇用您而感到高兴:)
dasblinkenlight 2012年

1
100%肯定是这种情况。实际上,我无法抗拒地给他发送一些链接以使他走上正确的道路,而不是因为没有得到演出而被刺戳,而是因为我实际上让他感到尴尬,并希望我能够帮助他不要两次犯同样的错误;)。
Matt Cashatt

4
然后,这似乎与技术堆栈无关,而与您更正他的事实有关。人们不喜欢被纠正。这只是人的本性。当人们做出诸如雇用员工之类的决定时,99%的人会凭直觉去做。无论您是否使他们感到正面或负面情绪,它们都会受到影响。纠正他可能使他感到负面情绪。然后他将这种消极情绪与局势联系起来。
编码器

1
我不知道哈希表在内部如何工作。像这样的深层技术测试却使受过实用思维训练的人仍然是优秀的候选人。对人们来说,要求他们拥有永远不会使用的低级知识对我来说似乎是不必要的。设计原则变得更加重要!
Tjaart 2012年

4

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

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

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


3

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

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


您可能将LINQ放入包含Nhibernate等的流行词池中……我不会这样做。实际上,我认为流行语是我们无法将抽象解释为正确表达的例证。
AndreasScheinert

您正在谈论“保持最新”,我认为相反的做法会更合适。过去已经发现并使用了许多有用的概念,例如DSL。我们需要改善对概念的交流和把握,例如我们不必为旧概念发明新的流行语。
AndreasScheinert 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.