La mejor manera de "presentar" OOP / OOD al equipo de ingenieros experimentados de C ++

Estoy buscando una manera eficiente, que tampoco sea un insulto, para presentar los conceptos de OOP a los miembros del equipo existentes Mis compañeros de equipo no son nuevos en los idiomas OO. Hemos estado haciendo C ++ / C # durante mucho tiempo, por lo que la tecnología en sí es familiar.

Sin embargo, miro a mi alrededor y sin una gran infusión de esfuerzo (principalmente en forma de revisiones de código), parece que lo que estamos produciendo es código C que está dentro de las clases. Casi no hay uso del principio de responsabilidad única, abstracciones o intentos de minimizar el acoplamiento, solo por nombrar algunos. He visto clases que no tienen un constructor pero ponen memset a 0 cada vez que se instancian.

Pero cada vez que menciono OOP, todos asienten y hacen que parezca que saben exactamente de lo que estoy hablando. Conocer los conceptos es bueno, pero a nosotros (algunos más que a otros) nos parece muy difícil aplicarlos cuando se trata de entregar un trabajo real.

Las revisiones de código han sido muy útiles, pero el problema con las revisiones de código es que solo ocurren después del hecho, por lo que para algunos parece que terminamos reescribiendo (principalmente refactorizando, pero todavía lleva mucho tiempo) el código que se acaba de escribir. Además, las revisiones de código solo brindan comentarios a un ingeniero individual, no a todo el equipo.

Estoy jugando con la idea de hacer una presentación (o una serie) e intentar volver a mostrar OOP junto con algunos ejemplos de código existente que podrían haberse escrito mejor y podrían ser refactorizados. Podría usar algunos proyectos realmente antiguos que ya nadie posee, así que al menos esa parte no debería ser un tema delicado. Sin embargo, ¿funcionará esto? Como dije, la mayoría de la gente ha hecho C ++ durante mucho tiempo, así que supongo que a) se sentarán allí pensando por qué les estoy diciendo cosas que ya saben ob) podrían tomarlo como un insulto porque estoy diciéndoles que no saben cómo hacer el trabajo que han estado haciendo durante años, si no décadas.

¿Existe otro enfoque que llegue a una audiencia más amplia que una revisión de código, pero al mismo tiempo no se sentiría como una conferencia de castigo?

No soy un chico recién salido de la universidad que tiene ideales utópicos de código perfectamente diseñado y no espero eso de nadie. La razón por la que escribo esto es porque acabo de hacer una revisión de una persona que realmente tenía un diseño decente de alto nivel en papel. Sin embargo, si imagina las clases: A -> B -> C -> D, en el código B, C y D implementan casi la misma interfaz pública y B / C tienen funciones de un solo revestimiento, por lo que la clase A más alta está funcionando absolutamente todo el trabajo (hasta gestión de memoria, análisis de cadenas, negociaciones de configuración ...) principalmente en 4 métodos mongo y, para todos los efectos, llama casi directamente a D.

Actualización: Soy un líder tecnológico (6 meses en este puesto) y tengo pleno apoyo del gerente del grupo. Estamos trabajando en un producto muy maduro y los costos de mantenimiento definitivamente se están dando a conocer.

¿Por qué no desarrolla una breve capacitación en los principios SÓLIDOS y les brinda esta capacitación? Parece que funcionó bastante bien para mí en mi organización actual y creo que dar entrenamientos cortos es realmente divertido (para todos los involucrados).

Cuando impartí mi capacitación, me tomé un tiempo para buscar ejemplos patológicos "malos" en el código existente (de varios proyectos) y los refactoré en la presentación, paso a paso, utilizando los principios. Esto demostró que

1. No es tan difícil hacer estas refactorizaciones
2. No toma mucho tiempo
3. El resultado final (cuidadosamente elegido ;-)) es claramente mejor que el código original.

Las revisiones de código han sido muy útiles, pero el problema con las revisiones de código es que solo ocurren después del hecho.

En un proyecto, hicimos revisiones de diseño.

15 minutos. En la pizarra blanca. Hable sobre el diseño antes de la codificación.

La parte más importante es programar la revisión del diseño antes de cualquier trabajo de implementación.

También tuvimos "Críticas críticas de diseño", que fueron un gran problema. Implicaban muchos documentos y una larga presentación. Fueron difíciles de programar y casi siempre se expulsaron hasta que comenzó la codificación, lo que redujo su valor a cero.

Las revisiones informales del diseño, antes de la codificación, sin presión, sin documentación, permiten una mejor discusión sobre cómo se asignan las responsabilidades y cómo colaborarán los objetos.

Supongo que eres más joven que algunos de los desarrolladores, pero más arriba en la cadena alimentaria.

A riesgo de ser enterrado en votos negativos, podría ser que los 'ingenieros experimentados' estén haciendo lo correcto, o dado que este es un producto maduro que puede haber existido durante décadas, lo que alguna vez fue lo correcto.

El código anterior tiende a haber sido optimizado para ejecutarse rápidamente en el hardware de la época; entre otras cosas, esto significa reducir los niveles de herencia y evitar llamadas a funciones / métodos para operaciones triviales.

Los compiladores se han vuelto mucho más inteligentes a lo largo de los años, por lo que no todo lo que alguna vez fue cierto ahora lo es, por ejemplo, un compilador puede optar por incorporar una pequeña función.

Quizás una ruta hacia adelante sería adoptar un enfoque diferente: pedir a los desarrolladores que expliquen cómo / por qué su método es mejor que la teoría que se les enseñó, y que sean sinceros al respecto.

Impulsar las pruebas unitarias con una cobertura de ramificación del 100% de cada método nuevo / modificado no conduciría a minimizar el acoplamiento entre los métodos.

Es posible que desee recoger el libro "Patrones de diseño" de la Banda de los Cuatro. No es específico de C ++, por lo que no critica abiertamente el conocimiento de C ++ de sus colegas cuando se refiere a él. Sin embargo, al mismo tiempo, aborda temas que considera relevantes. Además, el libro es ampliamente aceptado como relevante, por lo que no pueden descartarlo fácilmente como teórico o poco práctico.

Por otro lado, considere que C ++ no es un lenguaje OO puro, ni en diseño ni en la práctica. Toda la historia del constructor / memset parece que debes presentar RAII, que no es una técnica OO en absoluto, sino específica de C ++ (desafortunadamente, .Net IDispose muestra lo que sucede cuando RAII es una ocurrencia tardía). Los libros relevantes aquí son (Más) Efectivo C ++ y (Más) Excepcional C ++.