¿Está bien usar la meta-programación aunque no todos mis colegas lo entiendan?

La metaprogramación está bien. Lo que estás tratando de hacer no está bien.

Uso metaprogramación todo el tiempo en mi trabajo. Es una herramienta poderosa que se puede usar para hacer muchas cosas de una manera más fácil de leer y mantener. También es uno de los estilos de programación más difíciles de comprender, por lo que realmente necesita ganarse su sustento. Me gusta cuando puedo reducir 1000 líneas de código a 50, pero trato de limitarlo como tal.

El problema no es la metaprogramación, pero esto:

  

Por otro lado, todos somos desarrolladores profesionales de C ++ y creo que deberíamos aspirar a un estándar más alto que escribir C con clases.

Aquí es donde te metes en problemas. Tienes una opinión. Está bien tener una opinión de que la metaprogramación es buena. Está bien tener la opinión de que todos debemos aspirar a ser mejores desarrolladores de C ++.

No está bien compeler a sus colegas y futuros, quienes deberán mantener el código que escribió para estar de acuerdo con su opinión. Ese es el trabajo de tu jefe. Su jefe es quien debe preocuparse por asegurarse de que su código se pueda mantener a largo plazo. Ellos (con suerte) tienen mucha más experiencia empresarial, porque créanme cuando digo que es una decisión de negocios, no una decisión ideológica.

Está bien querer metaprogramar. Está bien querer enseñar a otros a metaprogramar. Pero comprenda que también está bien que otros elijan no aprender a metaprogramarse, y eso será cierto hasta que esté en una posición de poder. (y, como secreto de la industria: cuando finalmente eres un desarrollador líder, en una posición de poder, no estás en una posición de poder en absoluto. Hay alguien que controla las actividades que está en el poder).

Si desea animar a que estén bien con la metaprogramación, comience con poco . Comience con un solo enable_if que facilite la lectura de la API. Luego comenta las luces del día fuera de él. Entonces tal vez encuentre un caso en el que una metafunción de plantilla convierta 10 grandes clases repetitivas en 1 clase con 10 pequeños ayudantes. Comenta que diablos fuera de eso. Obtener comentarios. Encuentra lo que la gente piensa al respecto. Estaré bien si te dicen que no lo hagas. Encuentre un nicho donde la metaprogramación se gane tan bien que sus colegas estén de acuerdo (a regañadientes) en que fue la herramienta adecuada para el trabajo.

Como una historia corta, escribí una hermosa biblioteca una vez, utilizando una metaprogramación extensa. Hizo exactamente lo que necesitábamos en ese momento, cuando ningún otro enfoque podría acercarse remotamente. En realidad, cambió la dirección de la aplicación en la que estaba escribiendo. Pero fue metaprogramación. Solo una o dos personas más en mi compañía podrían leerlo.

Más tarde, mi colega dio otro golpe al problema. En lugar de aprovechar la metaprogramación para precisamente hacer lo que era necesario, trabajó con el liderazgo para relajar las limitaciones que se habían puesto en el problema, de modo que no era necesaria la metaprogramación. Quizás con más precisión, la metaprogramación era menos necesaria. Él fue capaz de limitarlo a lo que la metaprogramación hace mejor.

La biblioteca resultante se encuentra ahora en una posición para ser utilizada en un mercado de notablemente , y eso no es en gran parte debido al hecho de que el nuevo código se puede mantener en un rango mucho más amplio de desarrolladores. Estoy orgulloso de allanar el camino con la metaprogramación, pero es el código de mi colega el que llegará a un público más amplio, y hay buenas razones para ello.

En primer lugar, este es el problema del equipo, y usted tiene que resolverlo con el equipo. Si tiene una copia de seguridad del equipo para programar usando ciertos elementos y construcciones, hágalo; si no, discútala con ellos y si no puede convencerlos y defiende con firmeza que el "enfoque" es claramente mejor, será mejor que no lo utilice.

Tenga en cuenta que el uso de la meta-programación de plantillas en C ++ siempre es una compensación: seguro, a veces puede ayudar a diseñar ciertas partes de una aplicación más DRY, y es definitivamente útil para crear bibliotecas altamente eficientes y altamente reutilizables. / p>

Por otro lado, estos beneficios tienen un costo determinado: el código se vuelve más abstracto, a menudo mucho más difícil de leer, mucho más difícil de depurar y mucho más difícil de mantener. Esto hace que la utilidad de la meta-programación en la programación de aplicaciones a menudo sea cuestionable. Entonces, asumiendo que no va a crear el próximo STL, cada vez que tenga la tentación de usar la meta-programación, pregúntese si esos inconvenientes realmente valen la pena. Y si no está seguro, hable con su revisor durante la revisión del código.

Mi opinión general: si tiene una opción, como suele ser el caso, entre las siguientes tres opciones:

• Escriba muchas estructuras de código no triviales de forma repetitiva a mano;
• Use la metaprogramación de plantillas de C ++ para automatizar la generación de código;
• Utilice algún otro mecanismo de generación de código, como macros o algún otro lenguaje de programación para generar archivos fuente de C ++

luego, la metaprogramación de la plantilla, realizada correctamente, probablemente sea la más legible y fácil de mantener de las tres opciones. Este es el argumento que haría para el equipo, si estuviera en su posición. Los ejemplos con código real ayudarían a convencerlos.

Cuando use la Meta-Programación de Plantillas ( TMP ) para evitar la repetición, debe usarla para construir abstracciones bien documentadas y cuidadosamente probadas que localicen la complejidad dentro del código TMP, facilitando su escribir código de cliente correcto. Este es el diseño de la biblioteca estándar de C ++.

No creo que podamos juzgar quién está en lo correcto o incorrecto sin ver un ejemplo del tipo de código que estás tratando de escribir.

Los desarrolladores de software deben aspirar a escribir código que funcione, que funcione obviamente, que pueda probarse, revisarse, depurarse y adaptarse cuando se necesiten cambios. Si escribir "C con clases" logra esto, entonces está bien.

Y estos son los estándares con los que debes medir tu código. Especialmente: ¿Funciona obviamente? ¿Puede probarse, revisarse, depurarse y adaptarse cuando sea necesario?

Un argumento de compasión:

¿Su trabajo le da tiempo libre para aprender o, como alternativa, puede convencer a sus jefes para que asignen algunas horas para aprender estas características de lenguaje?

Si no, usarlos es, en esencia, darles trabajo adicional no pagado. Puede pensar que un programador de C ++ debería conocer todo el lenguaje, o algo así, pero un punto académico no alivia la carga que les impondrá. Sus colegas tienen hijos, padres enfermos, cónyuges enfermos, o el infierno, solo una vida social razonable que no implica aprender C ++. El oponente más vocal de tu propuesta puede ser perezoso, o puede estar pasando por un momento difícil y no necesita más mierda en su vida en este momento.

El código debe escribirse primero para que los humanos lo lean, y solo de forma incidental para que el compilador lo analice.

Ahora, lo que hay que recordar acerca de TMP no trivial es que está restringiendo el número de personas que pueden leer ese código, puede ser una compensación válida, pero diría que es mucho más que una compensación razonable en las bibliotecas y donde Usted tiene un pequeño equipo de expertos que se encuentra en una aplicación más grande.

Cuando saca todos los trucos del libro, impone costos a todos los demás, ya que ahora tienen que entender el lenguaje, incluidos todos los casos de abogados que ha explotado, también impone un costo de contratación que tiene. elevó la barra para trabajar en la aplicación de una manera útil, ahora tal vez valga la pena, pero vigile los costos ...

Para mí, un poco más de escritura, tal vez incluso un poco de duplicación de código, pero que puedo poner delante de Mr "C with classes plus STL" cuando se necesita modificación es mucho más útil que algo increíblemente elegante de TMP que solo Puedo mantener (y por lo tanto estaré manteniendo por siempre). Recuerde también que el C con las clases podría ser el experto en la materia, y que la experiencia suele ser mucho más valiosa que ser un abogado lingüístico.

Olvido quién lo dijo, pero "todo el mundo sabe que la depuración es más difícil que escribirlo en primer lugar, así que si lo programas tan inteligentemente como puedas, ¿cómo lo harás?".

Incluso si puedo escribir realmente el C ++ moderno que normalmente prefiero no hacerlo, significa que tengo que hacer menos de la programación de mantenimiento.

No, no deberías. Usted está empleado para producir código que satisfaga una especificación. Este código tiene que ser mantenido, no un viaje del ego. Puede ser atropellado por un autobús mañana, por lo que alguien tiene que poder recoger su código y progresar en la tarea en cuestión. Sin embargo, es positivo intentar convencer a sus empleadores para que incorporen nuevas técnicas en sus estándares de programación.

La única forma de responder esta pregunta en contexto es observar los problemas específicos y la forma específica en que los resolvió con la programación meta. A menos que publique el código aquí, no podemos saber si se entregó a una complicación innecesaria, lo cual es divertido solo para usted "resolver" un problema que no existe; o si utilizó toda la potencia del lenguaje para escribir una solución simple y elegante que no está disponible por otros medios.

Si es lo último, le animo a que continúe haciéndolo junto con su equipo. Todo buen equipo debe hacer revisiones de código significativas que traten no solo los problemas de estilo sino también si la solución del programador utiliza. el mejor enfoque, utiliza las funciones de lenguaje apropiadas, es mantenible y comprobable, etc. Su solución de metacomprobación debe completar una sesión de revisión de este tipo, probablemente toda una tarde. Los programadores que rechazan su enfoque deben establecer alternativas (como la generación de código con perl, la duplicación de código, etc.) y mostrar su desempeño en relación con los criterios mencionados, en comparación con su solución. Su trabajo, como su "oponente" amigable en el argumento, es demostrar que es una manera de hacer el trabajo rápido, que el mantenimiento es fácil, que las pruebas son fáciles y que el código es realmente legible una vez que supera el obstáculo de analizando la gramática divertida. (Si eres estratégico, puedes mostrárselo a un amigo en la oficina de antemano y convencerlo de que es realmente genial; eso te ayudará en la discusión porque no estarás solo).

La mayoría de los programadores son perezosos y disfrutan de soluciones pequeñas y elegantes. Si el suyo es uno, es probable que pueda convencerlos, especialmente si las alternativas demostradas no son suficientes.

No hay una sola respuesta correcta a esta pregunta.

Porque lo primero que debe preguntarse es: ¿en qué situación se encuentra su empleo? Algunas personas se emplean como monos codificados para codificar especificaciones, otras se emplean como jugadores de equipo, otras se emplean como expertos o trabajadores del conocimiento.

La única conclusión constante es que debe verlo desde la perspectiva de su empleador, ya que básicamente esto significa ser un empleado. A veces, lo mejor para su empleador es, de hecho, animar a sus colegas a ser mejores y dominar las técnicas avanzadas. Sin embargo, en una situación diferente, puede crear muchos problemas y responsabilidades y poner en peligro el éxito de los proyectos en los que está involucrado.

La pregunta no es realmente si la meta-programación está bien o no, sino más bien si está bien ser mejor que los demás en el equipo, así que aquí hay algunos puntos controvertidos sobre cómo lo veo ...

  

Hace poco me mudé a un nuevo trabajo en el que trabajo en un equipo más grande y esta [meta-programación] preocupa a algunos de mis colegas, porque no lo comprenden.

Están preocupados de que estés mejor que ellos. Eso es bueno. Vas a ser el nuevo experto. Acabas de destruir su mundo de statu quo.

  

Siempre trato de aprovechar todo el potencial del lenguaje, pero algunos (no todos) de mis colegas lo perciben como un riesgo (algunos aceptan el enfoque).

Claro, a nadie le gusta ser menos hábil que nadie, así que están tratando de evitar que uses técnicas que son demasiado complejas para ellos. O bien no pueden comprenderlo o no lo van a hacer porque se sienten seguros ahora.

  

Estoy de acuerdo en que es un problema escribir un código que nadie más en el equipo puede comprender.

Yo no. Creo que está mostrando su experiencia.

  

Mi pregunta es quién tiene razón, ¿qué debo hacer?

Debes usar todas tus habilidades para escribir el mejor código que puedas escribir y no mirar atrás a aquellos que no lo entienden. De lo contrario, te quedarás atascado en su nivel y serás solo un programador ordinario. Es bueno ser mejor que los demás, y es bueno esforzarse por ser mejor que ellos. Nunca obtendrás una nueva experiencia si no intentas usar nada nuevo o hacer las cosas de manera diferente.

Sé que voy a ser votado, pero así es como se ve. No es un crimen ser mejor que otros en el equipo, y no es un crimen usar tus habilidades. Es solo que todos tienen miedo de admitirlo ... porque están en el lado no capacitado y odian que el nuevo chico de repente pueda hacer algo que no pueden. Si fueran inteligentes, te pedirían ayuda y consejo, y no criticarían tu código por ser incomprensible.

EDIT

Parece que hay mucha confusión sobre esta pregunta. Como muestran los comentarios, muchas personas piensan que se trata de la legibilidad del código general. No, no es. Se trata de si ciertas características / construcciones del lenguaje deben prohibirse o evitarse porque algunos miembros del equipo no las entienden.

Mi respuesta es no . No deben ser prohibidos. Si quieres prohibir algo, ¿cómo harías eso? Tendría que preparar algún tipo de cuestionario para averiguar lo que los miembros de su equipo pueden y no pueden, o más bien no quieren aprender, ya que creo que todas las características de Languague son útiles en algún lugar, por lo que conocerlas y poder usarlas es siempre Bien y cuanto más sepa, mejor código puede escribir. También necesitaría una escala para definir qué funciones son principiantes, intermedias o avanzadas.

Para demostrar cuán tontas son estas restricciones, tomemos un ejemplo realmente simple: usted será contratado como ingeniero de software, pero su futuro jefe le dice que no se le permitirá usar do/while loops porque hay un par de personas en el equipo que nunca las han usado antes y tampoco van a hacerlo porque siempre han estado usando for loops para todo, por lo que encuentran confusa a do/while loops.

Ahora crees que esto es estúpido y loco, ¿verdad? Pero también lo es prohibir otras características. Algunas personas pueden usarlas y otras no quieren aprenderlas.

¿Por qué debería producir un código peor si sabe que hay algo que le permite hacer lo mismo con mucho menos esfuerzo y, a la vez, dar como resultado un código más robusto y legible?

Y no importa si usa solo las funciones básicas del lenguaje o las avanzadas, puede usar cualquiera de las dos para producir un código igualmente incomprensible e imposible de mantener, por lo que este es un tema completamente diferente.