¿Es aceptable utilizar funciones \ métodos lambda en software empresarial?

He notado publicaciones aquí que demuestran el uso de las funciones delegados \ lambda para resolver el agujero en la idea central sin mucha repetición: http://www.markhneedham.com/blog/2009/04/04/functional-c -el-agujero-en-el-medio-patrón /

El problema parece ser que los desarrolladores junior y otros no necesariamente entienden cuál es el concepto de función puntero de función \ delegado \ lambda, lo que parece dificultar la lectura (y posiblemente la depuración) del código.

¿Deberíamos evitar o limitar severamente el uso de esta herramienta en la redacción de software empresarial, especialmente en equipos pequeños o tiendas de desarrolladores únicos?

¿O es aceptable usarlo con los comentarios apropiados y esperar que cuando ya no esté cerca, el próximo desarrollador entienda o aprenda sobre las funciones lambda?

El problema parece ser que los desarrolladores junior y otros no necesariamente entienden cuál es el concepto de función puntero de función \ delegado \ lambda

Francamente, ese es su problema. Para eso te aseguras de que tengan entrenamiento. No puede no usar una buena técnica solo porque algunas personas podrían no entenderla. Si necesitan ayuda con eso, pueden venir a preguntarle al autor. Más importante aún, las funciones lambda se están convirtiendo en características del lenguaje extremadamente comunes.

¿No deberíamos usar la herencia porque algunas personas no la entienden? Demonios, algunas personas se niegan a creer en la ciencia o en los gérmenes o en cualquier forma de cosas ridículas. Debe poder seguir adelante y no dejar que la posibilidad de que otros no puedan seguirle el paso le impida escribir el mejor código que pueda. Las funciones de Lambda son una gran característica y una gran ayuda para escribir código, y debe tomar toda la ayuda que pueda obtener.

Un desarrollador debe saber cómo usar el lenguaje que es menor o no. Si no lo hacen, despídalos y encuentre a alguien que lo haga, o capacítelos para que lo hagan.

Sí, úsalos.

Soy un desarrollador junior y conozco / entiendo lambdas (y los otros conceptos que mencionaste). No hay nada que pueda evitar que un desarrollador junior aprenda todos esos conceptos en muy poco tiempo. Los jóvenes pueden no tener la misma cantidad de experiencia / experiencia cuando se trata de muchas trampas de desarrollo de software, sin embargo, conceptos como lambdas pueden ser fácilmente entendidos por cualquier persona con un conocimiento básico de programación y conexión a Internet. Además, parece extraño que haya elegido lambdas como ejemplo, teniendo en cuenta que si está usando C #, es probable que ni siquiera tenga mucha ventaja en aprender lambdas sobre los desarrolladores junior (solo se introdujeron en 2008, si yo recuerda correctamente).

En resumen, no hay necesidad de simplificar su código para los neófitos. Estaremos bien, y en realidad preferiríamos trabajar en la mejor implementación posible que se nos ocurra. :)

Si son una solución sensata a su problema, entonces debe usarlos.

No se restrinja artificialmente: es más probable que termine con un código de baja calidad que es difícil de mantener.

Si el código está bien escrito con los comentarios apropiados, los siguientes deberían poder aprender de usted.

Coloque un enlace a la documentación de msdn en los comentarios en la parte superior de un bloque que lo usa y luego continúe. No debe tener miedo de usar tecnología nueva / compleja, es parte del trabajo de los desarrolladores aprender cosas que no saben.

El problema parece ser que los desarrolladores junior y otros no necesariamente entienden cuál es el concepto de función puntero de función \ delegado \ lambda

Entonces necesitan aprenderlos. Período.

1. Este no es un rincón esotérico de C #. Debe comprenderlos para utilizar muchas bibliotecas .Net.
2. Este no es un tema de lenguaje esotérico, en general. Prácticamente todos los lenguajes de uso popular hoy en día tienen cierto sabor de puntero de función, y la mayoría tiene (o pronto lo están haciendo, en el caso de Java y C ++) cierres.

Solo tómate unos minutos para explicárselos. No es dificil.

Debe usar la herramienta adecuada para el trabajo. Si hay una manera más simple y clara de resolver el problema en cuestión, úselo. Si necesita profundizar en algo que cree que podría ser un tema avanzado para futuros mantenedores, márquelo claramente e incluya un puntero a la documentación que explique la técnica.

el puntero de función \ delegado \ concepto de función lambda

Cabe señalar que esas son tres cosas diferentes.

Dos escenarios posibles:

a) Sus colegas (o la mayoría de ellos) son razonablemente hábiles. Necesitan aprender lambdas, son parte del lenguaje y, a veces, son exactamente la herramienta adecuada para el trabajo. Entonces, cuando realmente son la mejor herramienta, por supuesto, úsalas. Simplemente evite usarlos porque acaba de enterarse de ellos y está emocionado y piensa que son una bala de plata.

b) Sus colegas (o la mayoría de ellos) son incompetentes. No hay forma de que nunca entiendan completamente las lambdas, los cierres, los punteros de función o cualquier otro concepto de metacodificación similar. Probablemente ya estén luchando por comprender los punteros, las referencias y la recursividad. En esta situación, lo mejor que puede hacer es morder la bala, usar una solución torpe, verbosa, libre de lambda y cepillar su CV, ya que debería buscar trabajo.

Aquí es donde la consistencia puede ayudar mucho. Si lo usa consistentemente con el mismo estilo, etc., entonces los lectores solo tienen que aprenderlo una vez, y luego lo reconocen en todas partes.

Además, podría ser explícito, al menos al principio. Por ejemplo, estos dos son equivalentes:

doSomething(() => someMethod());

doSomething(someMethod);

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

... pero en el primer caso, es obvio, si conoce la sintaxis lambda, lo que estamos haciendo. Incluso si no conoce la sintaxis lambda, es obvio que está viendo algo nuevo y tiene que buscarlo. En el segundo caso, parece que estás pasando una variable.

Sé que ReSharper lo empuja a cambiarlo al segundo caso, pero me pregunto si eso siempre es una buena idea. En el segundo caso, debes saber que se doSomethingnecesita un Action.

A menudo encuentro ciertos conceptos difíciles de entender porque solo se describen en abstracto, en lugar de encontrarlos en situaciones prácticas de la vida real. Así que personalmente estaría a favor de encontrar tales construcciones.

El escenario principal en el que puedo pensar para evitar hacer esto es si la programación no es la tarea principal de la otra persona. Por ejemplo, un administrador del sistema o un bioinformático que pasa la mayor parte del tiempo haciendo experimentos reales (una "rata de laboratorio").

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

Ahora, tal vez aquí estamos llamando DoAction porque su cuerpo es demasiado largo para caber dentro de la lambda misma. En ese caso, usar el método de extensión ForEach () a List no nos brinda muchos beneficios sobre el uso del bucle foreach regular, aunque supongo que guarda un par de líneas de código. Pero en este caso en particular, el uso de ForEach () puede habernos llevado a hacer algo que realmente requiere más código y causar un poco de agitación adicional en la pila de lo necesario; El argumento aprobado no necesita ser una Lambda en absoluto

Simplemente debe llamar a DoAction de esta manera:

itemsList.ForEach(DoAction);

No hay Lambda en absoluto. La clave es recordar qué es lo que realmente estás pasando cuando creas una expresión lambda: algo así como un atajo para definir una instancia de delegado. Sí, también tiene beneficios como el cierre, pero no se debe perder el sitio de lo que espera la llamada al método. En este caso, espera una dirección para un método que coincida con la firma de Action. DoAction ya es un método así, por lo que crear el lambda es solo agregar una llamada a un método totalmente innecesario.

En mi humilde opinión, escribir en cualquier nivel técnico superior al nivel técnico del equipo, está mal. Si los miembros de su equipo no se sienten realmente cómodos con las expresiones y funciones lambda y no tienen tiempo para aprenderlo (deberían dedicar su tiempo a la base de datos de ajuste de rendimiento, trabajar más en la interfaz de usuario, crear componentes, etc.), entonces sugiero no usarlos . Sin embargo, si están dispuestos a aprender y tienen tiempo libre, o si ya conocen el conocimiento, ¿por qué no?

Creo que este es un problema relativo que debe juzgarse por equipo y nivel técnico del equipo. Y este no es solo el caso de las funciones lambda. Este es el caso del conocimiento técnico. Entonces, por ejemplo, cada vez que un equipo conoce el patrón de repositorio tiene la experiencia para implementarlo y mantenerlo, entonces déjelo hacerlo. Pero si no lo hacen, simplemente encuentre otra forma. Si saben acerca de OO JavaScript, entonces déjenlos crear un código más escalable en JavaScript. Pero si no lo hacen, simplemente regrese a JavaScript procesal.