É aceitável usar funções \ métodos lambda em software comercial?

Notei postagens aqui demonstrando o uso das funções delegates \ lambda para resolver o buraco na idéia do meio sem muita repetição: http://www.markhneedham.com/blog/2009/04/04/functional-c -o-buraco-no-meio-padrão /

O problema parece ser que os desenvolvedores juniores e outros não necessariamente entendem qual é o conceito da função ponteiro da função \ delegate \ lambda, o que parece dificultar a leitura (e possivelmente a depuração) do código.

Devemos evitar ou limitar severamente o uso dessa ferramenta na criação de software comercial, especialmente em pequenas equipes ou em lojas exclusivas de desenvolvedores?

Ou é aceitável usá-lo com comentários apropriados e esperar que, quando eu não estiver mais por perto, o próximo desenvolvedor compreenda ou aprenda sobre as funções lambda?

O problema parece ser que os desenvolvedores juniores e outros não necessariamente entendem qual é o conceito da função ponteiro da função \ delegate \ lambda

Francamente, esse é o problema deles. É para isso que você garante que eles tenham treinamento. Você não pode deixar de usar uma boa técnica apenas porque algumas pessoas podem não entender. Se eles precisarem de ajuda, podem perguntar ao autor. Mais importante, as funções lambda estão se tornando recursos de linguagem extremamente comuns.

Não devemos usar herança porque algumas pessoas não a entendem? Inferno, algumas pessoas se recusam a acreditar em ciência ou germes ou qualquer tipo de coisa ridícula. Você precisa seguir em frente e não deixar que a possibilidade de que outras pessoas não possam acompanhá-lo o impeça de escrever o melhor código possível. As funções do Lambda são um ótimo recurso e ajudam muito na escrita de código, e você deve receber toda a ajuda possível.

Um desenvolvedor deve saber como usar o idioma em que é mais novo ou não. Se não o fizerem, demitam-no e encontrem alguém que o faça, ou treine-o para que o façam.

Sim, use-os.

Sou desenvolvedor júnior e conheço lambdas (e os outros conceitos que você mencionou). Não há nada que eu possa prever impedindo que um desenvolvedor júnior aprenda todos esses conceitos em um período muito curto de tempo. Os juniores podem não ter a mesma quantidade de experiência / conhecimento quando se trata de muitas dicas de desenvolvimento de software; no entanto, conceitos como lambdas podem ser facilmente compreendidos por qualquer pessoa com um conhecimento básico de programação e conexão à Internet. Além disso, parece estranho que você tenha escolhido lambdas como exemplo, considerando que, se estiver usando C #, é provável que você nem tenha uma vantagem no aprendizado de lambdas sobre os desenvolvedores juniores (eles só foram introduzidos em 2008, se eu lembre-se corretamente).

Em suma, não há necessidade de emburrecer seu código para nós, neófitos. Ficaremos bem e, na verdade, preferimos trabalhar na melhor implementação possível que você conseguir. :)

Se eles são uma solução sensata para o seu problema, você deve usá-los.

Não se restrinja artificialmente - é mais provável que você acabe com um código de baixa qualidade difícil de manter.

Se o código estiver bem escrito com os comentários apropriados, os participantes a seguir poderão aprender com você.

Coloque um link para a documentação do msdn nos comentários na parte superior de um bloco que o utiliza e, em seguida, vá em frente. Você não deve ter medo de usar tecnologia nova / complexa, faz parte do trabalho de desenvolvedores aprender coisas que eles não sabem.

O problema parece ser que os desenvolvedores juniores e outros não necessariamente entendem qual é o conceito da função ponteiro da função \ delegate \ lambda

Então eles precisam aprendê-los. Período.

1. Este não é um canto esotérico de C #. Você deve entendê-los para fazer uso de muitas bibliotecas .Net.
2. Este não é um tópico de idioma esotérico, em geral. Atualmente, praticamente todas as linguagens em uso popular têm algum tipo de ponteiro de função, e a maioria tem (ou está obtendo em breve, no caso de Java e C ++).

Apenas dedique alguns minutos para explicar a eles. Não é díficil.

Você deve usar a ferramenta certa para o trabalho. Se houver uma maneira mais simples e clara de resolver o problema em questão, use-o. Se precisar entrar em algo que você acha que pode ser um tópico avançado para futuros mantenedores, marque-o claramente e inclua um ponteiro para a documentação que explica a técnica.

o conceito da função ponteiro da função \ delegate \ lambda

Note-se que essas são três coisas diferentes.

Dois cenários possíveis:

a) Seus colegas (ou a maioria deles) são razoavelmente qualificados. Eles precisam aprender lambdas, fazem parte do idioma e, às vezes, são exatamente a ferramenta certa para o trabalho. Portanto, quando elas são realmente a melhor ferramenta, use-as de todos os modos. Apenas evite usá-los porque você mesmo aprendeu sobre eles e está animado e acha que eles são uma bala de prata.

b) Seus colegas (ou a maioria deles) são incompetentes. Não há como eles entenderem totalmente lambdas, fechamentos, ponteiros de função ou qualquer outro conceito semelhante de meta-codificação. Eles provavelmente já estão lutando para entender indicadores, referências e recursão. Nesta situação, o melhor que você pode fazer é morder a bala, usar uma solução desajeitada, detalhada e sem lambda, e retocar seu currículo, porque você deve procurar emprego.

É aqui que a consistência pode ajudar muito. Se você usá-lo consistentemente com o mesmo estilo, etc., os leitores precisam aprender apenas uma vez e reconhecê-lo em todos os lugares.

Além disso, pode ajudar a ser explícito, pelo menos a princípio. Por exemplo, esses dois são equivalentes:

doSomething(() => someMethod());

doSomething(someMethod);

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

... mas no primeiro caso, é óbvio, se você conhece a sintaxe lambda, o que estamos fazendo. Mesmo que você não conheça a sintaxe lambda, é óbvio que você está vendo algo novo e precisa procurar. No segundo caso, parece que você está passando uma variável.

Sei que o ReSharper leva você a alterá-lo para o segundo caso, mas me pergunto se é sempre uma boa ideia. No segundo caso, você precisa saber que doSomethingleva um Action.

Costumo achar certos conceitos difíceis de entender porque são apenas descritos em abstrato, em vez de encontrá-los em situações práticas da vida real. Então, eu pessoalmente seria a favor de encontrar essas construções.

O cenário principal em que posso evitar fazer isso é se a programação não é a principal tarefa da outra pessoa. Por exemplo, um administrador de sistemas ou um bioinformático que passa a maior parte do tempo realizando experimentos reais (um "rato de laboratório").

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

Agora, talvez aqui estamos chamando DoAction porque seu corpo é muito longo para caber dentro da própria lambda. Nesse caso, o uso do método de extensão ForEach () para List não nos oferece muitos benefícios sobre o uso do loop foreach regular, embora ele economize algumas linhas de código, suponho. Mas, nesse caso em particular, o uso de ForEach () pode ter nos levado a fazer algo que na verdade exige mais código e causa mais problemas na pilha do que o necessário; O argumento passado não precisa ser um Lambda

Você deve simplesmente chamar DoAction assim:

itemsList.ForEach(DoAction);

Sem Lambda. A chave é lembrar o que você realmente está passando quando cria uma expressão lambda: algo como um atalho para definir uma instância delegada. Sim, também possui benefícios como fechamento, mas não se deve perder o local do que a chamada de método está esperando. Nesse caso, está esperando um endereço para um método que corresponda à assinatura da ação. O DoAction já é esse método, portanto, criar o lambda é apenas adicionar uma chamada de método totalmente desnecessária.

IMHO, escrevendo em qualquer nível técnico superior ao nível técnico da equipe, está errado. Se os membros de sua equipe não estiverem realmente confortáveis ​​com expressões e funções lambda e não tiverem tempo para aprender (eles devem gastar seu tempo no banco de dados de ajuste de desempenho, trabalhar mais na interface do usuário, criar componentes etc.), então eu recomendo sugerir não usá-los . No entanto, se eles estão dispostos a aprender e têm tempo livre, ou já conhecem o conhecimento, por que não?

Eu acho que essa é uma questão relativa que deve ser julgada por equipe e nível técnico da equipe. E este não é apenas o caso das funções lambda. Este é o caso do conhecimento técnico. Portanto, por exemplo, sempre que uma equipe souber sobre o padrão do repositório, tiver o conhecimento necessário para implementá-lo e mantê-lo, faça-o. Mas se não o fizerem, simplesmente encontre outro caminho. Se eles souberem sobre o JavaScript OO, crie um código mais escalável no JavaScript. Mas, se não, basta voltar ao JavaScript processual.