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.