Este tema se relaciona con el desarrollo web/ingeniería de software; sin embargo, la pregunta puede estar relacionada con otros campos de especialización que involucran a un empleado más joven que tiene más habilidades técnicas que un senior con más experiencia.
Trabajo en un equipo donde la extensión absoluta de la programación orientada a objetos utilizada es la herencia . El código de procedimiento se coloca en métodos de clase. Hay poca o ninguna sugerencia de tipo en las firmas de métodos, no hay espacios de nombres o interfaces (lo sé, ¿verdad)? - Esto ha llevado a un código heredado que es difícil de mantener y muy difícil de aprender y trabajar para el personal nuevo (junior). Solo la persona que lo escribió sabe realmente cómo funciona.
En una reunión técnica sobre un nuevo proyecto, anticipo que cualquier discusión sobre buenas prácticas de OO (patrones de diseño, etc.) probablemente se encontrará con "es demasiado complejo". Demasiado complejo siendo 5 clases o más.
Soy educado, tranquilo, respetuoso y honesto, al igual que el desarrollador sénior: es un amigo. Como resultado, él cree honestamente que cualquier cosa por encima de la herencia en la programación es "demasiado compleja" y honestamente creo que no lo es, habiendo escrito código en el pasado que "simplemente funcionó", ya que yo mismo lo probé por completo y funcionó perfectamente en el día del lanzamiento, y el código del senior requirió algunas correcciones.
¿Cómo puedo presentar una buena solución orientada a objetos que sea arquitectónicamente sólida y "tenga sentido" en esta reunión pero evite el problema de "es demasiado complicado" (cuando en realidad no lo es, es solo que él está acostumbrado a codificar en estilo procedimental) . Tengo el mayor respeto por mi superior, pero quiero evitar el terrible código de procedimiento (en las clases) que ahora tiene nuestra aplicación heredada.
¿Cómo puede una persona más joven, con mucha menos experiencia, pero mucho más empuje (habiendo aprendido estos conceptos y puesto en práctica en múltiples ocasiones), convencer a una persona mayor de que esta es la mejor manera, con el debido respeto y tacto?
Tú les muestras.
Estuve en muchos lugares donde necesitaba capacitar a la gente y, con los años, descubrí que hablar de las cosas no es suficiente. Las personas recurrirán a sus experiencias y, en su experiencia, la programación orientada a objetos (OO) hace que las cosas sean demasiado complejas. Lo que tienes que hacer es mostrarles valor .
Toma un problema que tengan y conozcan, y resuélvelo como lo harías tú. Muéstreles cómo su solución proporciona un valor agregado sobre lo que saben. Esto les da una base para el aprendizaje, y a ambos les da una base concreta para la discusión en lugar de una teórica que muchos descartarán sin más.
Pero eso no es suficiente por sí mismo (para la mayoría de las personas). Su solución seguirá pareciendo demasiado complicada porque los conceptos nuevos/novedosos son invariablemente más trabajo para las personas que lo que saben. El siguiente paso es tomar un ejemplo relativamente simple y lograr que lo usen . Si fuera un desarrollador senior, diría que implemente algún código OO y deje que otros corrijan errores en él. Como desarrollador junior, no estoy seguro. Para algunas personas, tratar de que vayan a un campamento de programación o trabajen en algún proyecto de pasatiempo puede ser un incentivo bastante interesante. Pero es posible que solo necesite implementar algunas funciones de manera OO y hacer que el senior trabaje con ellas (corrección de errores, extensiones, etc.).
En mi experiencia, las personas solo creen realmente cuán fácil/bueno puede ser algo cuando realmente lo han usado ellos mismos.
Juan76
gnasher729
DJClayworth
Jaime
keshlam
Jaime