Est-il acceptable d'utiliser les fonctions \ méthodes lambda dans les logiciels d'entreprise?

J'ai remarqué ici des articles démontrant l'utilisation des fonctions delegates \ lambda pour résoudre le trou dans l'idée centrale sans beaucoup de répétitions: http://www.markhneedham.com/blog/2009/04/04/functional-c -le-trou-au-milieu-motif /

Le problème semble être que les développeurs juniors et autres ne comprennent pas nécessairement ce qu'est le concept de fonction pointeur \ délégué \ lambda, ce qui semble rendre la lecture (et éventuellement le débogage) du code plus difficile.

Devrions-nous éviter ou limiter sérieusement l'utilisation de cet outil dans la rédaction de logiciels d'entreprise, en particulier dans les petites équipes ou les boutiques de développeurs uniques?

Ou est-il acceptable de l'utiliser avec des commentaires appropriés et de m'attendre à ce que lorsque je ne serai plus là, le prochain développeur comprendra ou en apprendre davantage sur les fonctions lambda?

Le problème semble être que les développeurs juniors et autres ne comprennent pas nécessairement ce qu'est le concept de fonction pointeur \ délégué \ fonction lambda

Franchement, c'est leur problème. C'est pour cela que vous vous assurez qu'ils ont une formation. Vous ne pouvez pas ne pas utiliser une bonne technique simplement parce que certaines personnes pourraient ne pas la comprendre. S'ils ont besoin d'aide, ils peuvent venir demander à l'auteur. Plus important encore, les fonctions lambda deviennent des fonctionnalités de langage extrêmement courantes.

Ne devrions-nous pas utiliser l'héritage parce que certaines personnes ne le comprennent pas? Enfer, certaines personnes refusent de croire à la science ou aux germes ou à toute sorte de choses ridicules. Vous devez pouvoir avancer et ne pas laisser la possibilité que d'autres ne puissent pas vous suivre vous empêcher d'écrire le meilleur code possible. Les fonctions Lambda sont une excellente fonctionnalité et aident grandement à écrire du code, et vous devriez prendre toute l'aide que vous pouvez obtenir.

Un développeur doit savoir comment utiliser le langage qu'il est débutant ou non. S'ils ne le font pas, alors tirez-les et trouvez quelqu'un qui le fait, ou formez-les pour qu'ils le fassent.

Oui, utilisez-les.

Je suis un développeur junior et je connais / comprends les lambdas (et les autres concepts que vous avez mentionnés). Il n'y a rien que je puisse prévoir pour empêcher un développeur junior d'apprendre tous ces concepts en très peu de temps. Les juniors peuvent ne pas avoir la même expérience / expertise en matière de développement de logiciels, cependant, des concepts tels que lambdas peuvent être tout aussi facilement compris par quiconque ayant une compréhension de base de la programmation et une connexion Internet. En outre, il semble étrange que vous choisissiez les lambdas comme exemple, étant donné que si vous utilisez C #, il est probable que vous n'ayez même pas une longueur d'avance sur l'apprentissage des lambdas par rapport aux développeurs juniors (ils n'ont été introduits qu'en 2008, si je rappelez-vous correctement).

En bref, il n'est pas nécessaire d'abaisser votre code pour nous, néophytes. Nous serons très bien, et préférerions en fait travailler sur la meilleure implémentation possible que vous pouvez trouver. :)

S'ils sont une solution sensée à votre problème, vous devez les utiliser.

Ne vous limitez pas artificiellement - vous êtes plus susceptible de vous retrouver avec un code de mauvaise qualité difficile à maintenir.

Si le code est bien écrit avec des commentaires appropriés, ceux qui suivent devraient pouvoir apprendre de vous.

Mettez un lien vers la documentation msdn dans les commentaires en haut d'un bloc qui l'utilise puis allez-y. Vous ne devriez pas avoir peur d'utiliser des technologies nouvelles / complexes, cela fait partie du travail des développeurs d'apprendre des choses qu'ils ne connaissent pas.

Le problème semble être que les développeurs juniors et autres ne comprennent pas nécessairement ce qu'est le concept de fonction pointeur \ délégué \ fonction lambda

Ensuite, ils doivent les apprendre. Période.

1. Ce n'est pas un coin ésotérique de C #. Vous devez les comprendre pour utiliser de nombreuses bibliothèques .Net.
2. Ce n'est pas un sujet de langage ésotérique, en général. Presque tous les langages couramment utilisés aujourd'hui ont une certaine saveur de pointeur de fonction, et la plupart ont (ou obtiennent bientôt, dans le cas de Java et C ++) des fermetures.

Prenez juste quelques minutes pour leur expliquer. C'est pas difficile.

Vous devez utiliser le bon outil pour le travail. S'il existe un moyen plus simple et plus clair de résoudre le problème, utilisez-le. Si vous devez aborder quelque chose qui pourrait être un sujet avancé pour les futurs responsables, marquez-le clairement et incluez un pointeur vers la documentation qui explique la technique.

le concept de fonction pointeur \ délégué \ fonction lambda

Il convient de noter que ce sont trois choses différentes.

Deux scénarios possibles:

a) Vos collègues (ou la plupart d'entre eux) sont raisonnablement qualifiés. Ils ont besoin d'apprendre les lambdas, ils font partie de la langue, et parfois, ils sont exactement le bon outil pour le travail. Alors, quand ils sont en effet le meilleur outil, utilisez-les. Évitez simplement de les utiliser parce que vous venez de les découvrir vous-même et vous êtes tous excités et pensez qu'ils sont une solution miracle.

b) Vos collègues (ou la plupart d'entre eux) sont incompétents. Il n'y a aucun moyen qu'ils puissent comprendre pleinement les lambdas, les fermetures, les pointeurs de fonction ou tout autre concept de méta-codage similaire. Ils ont probablement du mal à comprendre les pointeurs, les références et la récursivité déjà. Dans cette situation, le mieux que vous puissiez faire est de mordre la balle, d'utiliser une solution maladroite, verbeuse et sans lambda, et de rafraîchir votre CV, car vous devriez être à la recherche d'un emploi.

C'est là que la cohérence peut beaucoup aider. Si vous l'utilisez de manière cohérente avec le même style, etc., les lecteurs ne doivent l'apprendre qu'une seule fois, puis ils le reconnaissent partout.

En outre, il pourrait être utile d'être explicite, du moins au début. Par exemple, ces deux sont équivalents:

doSomething(() => someMethod());

doSomething(someMethod);

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

... mais dans le premier cas, il est évident, si vous connaissez la syntaxe lambda, ce que nous faisons. Même si vous ne connaissez pas la syntaxe lambda, il est évident que vous voyez quelque chose de nouveau et que vous devez le rechercher. Dans le second cas, on dirait que vous passez une variable.

Je sais que ReSharper vous pousse à le changer pour le deuxième cas, mais je me demande si c'est toujours une bonne idée. Dans le second cas, vous devez savoir que cela doSomethingprend un Action.

Je trouve souvent certains concepts difficiles à comprendre car ils ne sont décrits que dans l'abstrait, plutôt que de les rencontrer dans des situations pratiques et réelles. Je serais donc personnellement en faveur de rencontrer de telles constructions.

Le scénario principal auquel je peux penser pour éviter de faire cela est que la programmation ne soit pas la tâche principale de l'autre personne. Par exemple, un administrateur système ou un bioinformaticien qui passe la plupart de son temps à faire de réelles expériences (un "rat de laboratoire").

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

Maintenant, peut-être que nous appelons ici DoAction parce que son corps est trop long pour tenir dans le lambda lui-même. Dans ce cas, l'utilisation de la méthode d'extension ForEach () pour lister ne nous donne pas beaucoup d'avantages par rapport à l'utilisation de la boucle foreach normale, bien qu'elle enregistre quelques lignes de code, je suppose. Mais dans ce cas particulier, l'utilisation de ForEach () peut nous avoir endormis en faisant quelque chose qui prend en fait plus de code, et provoquant un thrashing supplémentaire sur la pile que nécessaire; L'argument passé n'a pas du tout besoin d'être un Lambda

Vous devez simplement appeler DoAction comme ceci:

itemsList.ForEach(DoAction);

Pas de Lambda du tout. La clé est de se rappeler ce que vous passez vraiment lorsque vous créez une expression lambda: quelque chose d'un raccourci pour définir une instance de délégué. Oui, il présente également des avantages tels que la fermeture, mais il ne faut pas perdre de vue ce que l'appel de méthode attend. Dans ce cas, il attend une adresse vers une méthode qui correspond à la signature d'Action. DoAction est déjà une telle méthode, donc la création du lambda ne fait qu'ajouter un appel de méthode totalement inutile.

IMHO, écrivant à un niveau technique supérieur au niveau technique de l'équipe, a tort. Si les membres de votre équipe ne sont pas vraiment à l'aise avec les expressions et la fonction lambda et qu'ils n'ont pas le temps de l'apprendre (ils devraient consacrer leur temps à la base de données d'optimisation des performances, travailler davantage sur l'interface utilisateur, créer des composants, etc.), alors j'ai fortement suggérer de ne pas les utiliser . Cependant, s'ils sont disposés à apprendre et à avoir du temps libre, ou s'ils connaissent déjà les connaissances, alors pourquoi pas?

Je pense que c'est une question relative qui doit être jugée par équipe et par niveau technique de l'équipe. Et ce n'est pas seulement le cas des fonctions lambda. C'est le cas des connaissances techniques. Ainsi, par exemple, chaque fois qu'une équipe connaît le modèle de référentiel a l'expertise pour l'implémenter et le maintenir, alors laissez-le faire. Mais s'ils ne le font pas, trouvez simplement un autre moyen. S'ils connaissent OO JavaScript, alors créons un code plus évolutif en JavaScript. Mais s'ils ne le font pas, revenez simplement au JavaScript procédural.