在商业软件中使用lambda函数\方法是否可以接受？

我注意到这里的帖子演示了使用proxys \ lambda函数来解决中间思想上的漏洞而无需大量重复：http : //www.markhneedham.com/blog/2009/04/04/functional-c中间图案的孔/

问题似乎是初级开发人员和其他开发人员不一定了解函数指针\委托\ lambda函数概念是什么，这似乎使阅读（并可能调试）代码更加困难。

我们是否应该避免或严格限制在编写商业软件时使用此工具，特别是在小型团队或唯一的开发商商店中？

还是可以在适当的注释中使用它，并期望当我不再使用它时，下一个开发人员将理解或了解lambda函数？

问题似乎是初级开发人员和其他开发人员不一定了解函数指针\委托\ lambda函数概念是什么

坦率地说，这就是他们的问题。这就是您确保他们接受培训的目的。您不能仅仅因为某些人可能不理解它就使用一种好的技术。如果他们需要帮助，可以来询问作者。更重要的是，lambda函数正成为极其通用的语言功能。

我们是否应该因为某些人不理解继承而使用继承？地狱，有些人拒绝相信科学或细菌或任何形式的荒谬事物。您必须能够继续前进，而不是让其他人无法跟上您的可能性阻止您编写可能的最佳代码。Lambda函数是一个很棒的功能，可以极大地帮助您编写代码，因此您应该尽一切可能获得帮助。

开发人员应该知道如何使用他们不熟悉的语言。如果他们不这样做，则将其解雇并找人去做，或者训练他们这样做。

是的，使用它们。

我是一名初级开发人员，我了解/理解lambda（以及您提到的其他概念）。我没有什么可以阻止初级开发人员在很短的时间内学习所有这些概念的。在软件开发的许多方面，大三学生可能没有相同的经验/专长，但是，对lambda之类的概念可以很容易被任何对编程和互联网连接有基本了解的人理解。同样，选择lambda作为示例似乎很奇怪，考虑到如果您使用的是C＃，您可能甚至没有在初级开发人员上学习lambda的那么多开端（它们只是在2008年推出，如果我请记住正确）。

简而言之，无需为新手编写代码。我们会好起来的，实际上，我们更愿意尝试您可以想到的最佳实现。:)

如果它们是您问题的明智解决方案，则应使用它们。

不要人为地限制自己-您更有可能遇到难以维护的劣质代码。

如果代码编写得当，并带有适当的注释，则随后的内容应该可以向您学习。

在使用它的块的顶部的注释中放入msdn文档的链接，然后继续。您不应该害怕使用新的/复杂的技术，这是开发人员学习他们不了解的事情的一部分。

问题似乎是初级开发人员和其他开发人员不一定了解函数指针\委托\ lambda函数概念是什么

然后他们需要学习它们。期。

1. 这不是 C＃的深奥技巧。您必须了解它们才能使用许多.Net库。
2. 通常，这不是一个深奥的语言主题。如今，几乎每种流行的语言几乎都具有某种功能指针，并且大多数都有（或在Java和C ++的情况下很快会出现）闭包。

请花几分钟向他们解释一下。不难

您应该为作业使用正确的工具。如果有解决当前问题的更简单，更清晰的方法，请使用该方法。如果您需要进入一些您认为可能对将来的维护者来说是高级主题的内容，请对其进行清楚的标记，并提供指向说明该技术的文档的指针。

函数指针\委托\ lambda函数概念

应该注意的是，这是三件事。

两种可能的情况：

a）您的同事（或其中大多数）是相当熟练的。他们需要学习lambda，它们是语言的一部分，有时，它们正是这项工作的正确工具。因此，当它们确实是最好的工具时，请务必使用它们。只是避免使用它们，因为您自己才刚刚了解它们，并且您都很兴奋，并认为它们是银弹。

b）您的同事（或其中大多数）无能。他们不可能完全理解lambda，闭包，函数指针或任何其他类似的元编码概念。他们可能已经在努力理解指针，引用和递归。在这种情况下，您最好的办法就是硬着头皮，使用笨拙，冗长，无lambda的解决方案，并重新整理简历，因为您应该找工作。

这是一致性可以带来很多帮助的地方。如果您以相同的样式等一致地使用它，那么读者只需学习一次，然后他们到处都可以识别它。

另外，至少在一开始时，将其明确可能会有所帮助。例如，这两个是等效的：

doSomething(() => someMethod());

doSomething(someMethod);

private void doSomething(Action someAction) { ... }
private void someMethod() { ... }

...但是在第一种情况下，很明显，如果您知道lambda语法，那么我们正在做什么。即使您不知道lambda语法，也很明显您看到的是新内容，因此必须查找它。在第二种情况下，看起来好像您正在传递变量。

我知道ReSharper会促使您将其更改为第二种情况，但是我想知道这是否总是一个好主意。在第二种情况下，您必须知道doSomething需要Action。

我经常发现某些概念很难理解，因为它们仅是抽象描述的，而不是在实际的现实生活中遇到的。因此，我个人赞成遇到这样的结构。

我可以想到的避免这种情况的主要场景是，编程不是对方的主要任务。例如，花费大部分时间进行实际实验的系统管理员或生物信息学家（“实验室老鼠”）。

itemsList.ForEach(item => DoAction(item));
...
public void DoAction(Item item) {
  //...do various things here...
}

现在，也许在这里我们称其为DoAction，因为其主体太长而无法放入lambda本身。在那种情况下，使用List的ForEach（）扩展方法与使用常规的foreach循环相比，并没有给我们带来很多好处，尽管我确实节省了几行代码。但是在这种情况下，使用ForEach（）可能使我们无法做实际上占用更多代码的事情，并在堆栈上造成不必要的额外抖动；通过的论点根本不需要是lambda

您应该像这样简单地调用DoAction：

itemsList.ForEach(DoAction);

完全没有Lambda。关键是要记住创建lambda表达式时实际上传递的是什么：定义委托实例的捷径。是的，它还具有诸如闭包之类的好处，但您不应失去该方法调用的期望。在这种情况下，需要一个与Action签名匹配的方法的地址。DoAction已经是这样的方法，因此创建lambda只是添加了一个完全不必要的方法调用。

恕我直言，以高于团队技术水平的任何技术水平进行写作都是错误的。如果您的团队成员对lambda表达式和函数不太满意，并且他们没有时间花时间学习它们（他们应该将时间花在性能调整数据库上，更多地使用UI，创建组件等），那么我强烈建议建议不要使用它们。但是，如果他们愿意学习并有空闲时间，或者他们已经知道这些知识，那为什么不呢？

我认为这是一个相对的问题，应该根据团队和团队的技术水平来判断。这不仅是lambda函数的情况。这是技术知识的情况。因此，例如，只要团队知道存储库模式具有实施和维护它的专业知识，那就让我们来做。但是，如果他们不这样做，那就简单地寻找另一种方法。如果他们了解OO JavaScript，那么让我们在JavaScript中创建更多可扩展的代码。但是，如果不这样做，只需返回程序JavaScript。