Consejos sobre cómo difundir prácticas orientadas a objetos [cerrado]

Trabajo para una empresa mediana que tiene alrededor de 250 desarrolladores. Desafortunadamente, muchos de ellos están atrapados en una forma de pensar de procedimiento y algunos equipos constantemente entregan grandes aplicaciones de Transactional Script , cuando de hecho la aplicación contiene una lógica rica. Tampoco logran administrar las dependencias de diseño y terminan con servicios que dependen de otro gran número de servicios (un ejemplo claro de Big Ball of Mud ).

Mi pregunta es: ¿Puedes sugerir cómo difundir este tipo de conocimiento?

Sé que la superficie del problema es que estas aplicaciones tienen una arquitectura y un diseño deficientes. Otro problema es que hay algunos desarrolladores que están en contra de escribir cualquier tipo de prueba.

Algunas cosas que estoy haciendo para cambiar esto (pero estoy fallando o el cambio es demasiado pequeño son)

• Ejecución de presentaciones sobre principios de diseño (SÓLIDO, código limpio, etc.).
• Talleres sobre TDD y BDD.
• Coaching de equipos (esto incluye el uso de sonar, findbugs, jdepend y otras herramientas).
• IDE y refactorización de conversaciones.

Algunas cosas que pienso hacer en el futuro (pero me preocupa que no sean buenas)

• Forme un equipo de evangelistas OO, que difunda una forma de pensar OO en diferentes equipos (estas personas tendrían que cambiar de equipo cada pocos meses).
• Ejecución de sesiones de revisión de diseño, para criticar el diseño y sugerir mejoras (incluso si las mejoras no se realizan debido a limitaciones de tiempo, creo que esto podría ser útil)

.

Algo que encontré con los equipos que entreno es que tan pronto como los dejo, vuelven a las viejas prácticas. Sé que no paso mucho tiempo con ellos, generalmente solo un mes. Lo que sea que esté haciendo, no se pega.

Lamento que esta pregunta esté salpicada de frustración, pero la alternativa para escribir esto fue golpearme la cabeza contra la pared hasta desmayarme.

No intentes presionar a OOP, solo empeorará las cosas. No porque OOP es una mala idea en general: no lo es. Pero porque parece que quien sea responsable de ese código no solo carece de las herramientas para evitar estos problemas, sino también la experiencia y, lo que es más importante, la motivación.

Las personas que desean escribir código limpio lo harán en cualquier paradigma dado, ya sea OOP, de procedimiento, funcional, etc. Pero no todos los programadores son así, y si empujas cualquier herramienta de código limpio a personas que no lo hacen Comprenda la necesidad, terminará abusando de estas herramientas como las herramientas que ya están allí. Verá métodos no relacionados agrupados en una clase, clases heredadas de clases no relacionadas, visibilidad de métodos establecida en base a depuración de prueba y error en lugar de diseño consciente, métodos estáticos que no deberían ser estáticos y métodos no estáticos que deberían, en resumen , perderás tu tiempo.

En cambio, vea si puede invertir en aumentar la conciencia para mantener la elegancia y el mantenimiento. Después de todo, los objetivos centrales de OOP no son diferentes de cualquier otra estrategia de gestión de la complejidad (que es de lo que se tratan realmente los paradigmas de programación): encapsulación, modulación, acoplamiento flexible, bajo grado de interdependencia, mantener el estado mutable y su alcance para un mínimo, etc. etc. OOP ciertamente no es el único paradigma que le brinda las herramientas que necesita para lograr esto.

Lo que me lleva al último punto: OOP es una gran idea, y funciona bien para ciertos tipos de problemas, pero (y estoy hablando tanto desde mi propia experiencia como parafraseando la opinión de algunas grandes mentes aquí) para muchos tipos de problemas. problemas, es completamente inadecuado. Cuando estás recién entrado en OOP, y el código de espagueti semi-procesal es la única alternativa con la que estás familiarizado, OOP aparece naturalmente como un regalo del cielo (y de una manera relativa), y es probable que te acerques Todos los problemas como clavos para su martillo OOP. Eso es natural, y llevar a OOP a (y más allá) sus limitaciones es una buena manera de desarrollar sus habilidades de OOP, por lo que no todo es negativo. Pero tal vez (solo tal vez) esta base de código en particular no necesita OOP después de todo. Tal vez se beneficiaría mucho más de una arquitectura procesal,

TL; DR: Si quieres evangelizar algo, deja que sean buenas prácticas de codificación (agnósticas), no un paradigma o metodología en particular.

No puedes hacer cambiar a nadie que ya no quiera cambiar. Es por eso que los equipos que has entrenado han vuelto a sus viejas costumbres.

Entonces, su pregunta debería ser "¿cómo hago para que los desarrolladores quieran cambiar a enfoques OO?"

Comience simple, comience con poco, deje que las cosas se desarrollen a partir de ahí. Muestre los beneficios al desarrollador individual en lugar de los beneficios abstractos o filosóficos para el código, otros desarrolladores o la empresa.

Muestre cómo las diversas técnicas de OO conducirán a menos código que tienen que escribir, así como a tiempos de desarrollo más rápidos. Casi cualquier desarrollador escuchará una propuesta que facilitará su trabajo.

Luego comience a demostrar cómo las técnicas OO conducirán a un código más fácil de mantener. Todos en ese tipo de entorno viven con el temor de hacer " el cambio " que borra un tercio de la aplicación de producción. La encapsulación es la clave para evitar este riesgo y permite que cada capa (próximamente) de la aplicación mantenga su contrato con las otras capas.

Me gustaría ver cómo se transmiten los datos. Si es una larga lista de variables cada vez, considere incluir algunas de ellas dentro de una estructura (o ¡jadear! ¡Una clase!) Como un paso preliminar. Simplemente envolver los datos dentro de un objeto es el comienzo de los contratos entre capas.

En un nivel más amplio, considere obtener la aceptación de la gerencia para este esfuerzo si aún no lo ha hecho. La gerencia necesita ver los beneficios concretos de la disminución de defectos y el menor riesgo de realizar cambios. Finalmente, el proceso de refactorización debería conducir a tiempos de desarrollo más rápidos, pero eso es un beneficio a largo plazo.

Sus ideas de equipos de revisión y evangelistas de OO son buenas. Tiene que ser más que solo usted quien impulsa esta agenda.

Mi experiencia es que cambiar de mentalidad procesal a mentalidad OO es un gran obstáculo. Requiere perseverancia que muchos desarrolladores no pueden soportar. Esto se debe principalmente a que se pasan por alto los fundamentos de OO.

Forme un equipo de evangelistas OO, que difunda una forma de pensar OO en diferentes equipos (estas personas tendrían que cambiar de equipo cada pocos meses).

es una buena idea. Esto debe ser exhaustivo y se debe hablar de OO desde cero. Cuando estaba aprendiendo OO, las anécdotas históricas me ayudaron mucho.

También sugeriría

• Dado que la motivación es la clave, motívelos detallando cómo OO puede mejorar su trabajo, especialmente el mantenimiento del código.
• Revise el código y muestre cómo refactorizar aplicando composición, herencia, polimorfismo y patrones.
• Introduzca un buen proceso como SCRUM e involucre a los desarrolladores en él.
• Haga que la lectura de libros como 'Refactorización' y 'Refactorización a patrones' sea obligatoria.

Estoy de acuerdo con Shuvo Naser. Es un gran obstáculo, así que trátalo más como una escalada. Aprender a diseñar una aplicación completa con OOP llevará tiempo.

1. Identifique a aquellos que entienden OOP y acérquelos a los líderes de equipo, entrenadores, diseñadores, revisores de códigos, etc.
2. Use un proyecto existente como referencia de capacitación. Posiblemente aquellos en el # 1 estaban en ese equipo.
3. Refactorizar algunos proyectos existentes. Esto puede ayudar a algunas personas a construir un puente entre su código de procedimiento y el código OO. Comience con lo básico. Tienen que ver cuándo, dónde y por qué usas estos principios.
4. Involúcrelos en sesiones de diseño con personas que saben lo que están haciendo.
5. Póngalos en equipos de desarrollo con alguien que pueda proporcionar orientación de diseño y asegurarse de que el proyecto se apegue a los principios de OO (Suponiendo que la razón por la que desea hacer esto es porque mejorará el desarrollo).

La adopción rara vez precede a ver los beneficios. Estamos hablando de un diseño complejo y no utilizamos las hojas de portada de informes TPS .

Ya tienes buenas ideas

Las ideas que delineas en tu pregunta suenan excelentes. Es una gran sorpresa que no encuentres el éxito. Es 2012 y la revolución orientada a objetos ha pasado desde hace mucho tiempo del estado de la técnica al estado de la práctica. Parece que a menos que tenga muy poca rotación y muy poca contratación, le resultaría difícil no obtener varias docenas o incluso cien buenos programadores orientados a objetos sólidos.

¿Ágil u orientado a objetos?

Usted menciona algunas tecnologías ágiles como TDD y algunos conceptos más nuevos, por lo que no sea demasiado duro con las personas por no adoptar algo que todavía luchan activamente algunos equipos de gestión. Algunos afirman abrazar a Agile, pero cuando hablan de eso, significa lo que dicen que significa. La organización no se caracteriza por equipos que toman decisiones y se adaptan, sino por un fuerte control jerárquico de estilo contractual.

Pero volvamos a la orientación a objetos. No menciona el análisis o diseño orientado a objetos, y no estoy muy seguro de qué lenguaje de programación está dando paso a qué lenguaje de programación orientado a objetos. Sé que UML está teniendo problemas de popularidad entre muchos programadores orientados a objetos. Después de haber sido completamente entrenado en OOAD, creo que puede ser como aprender la cultura y la historia de un país cuyo idioma natural desea aprender. Por ejemplo, si quisiera aprender griego, podría aprender el alfabeto, el vocabulario y la gramática, pero si ignorara la rica historia y cultura, extrañaría mucho. En cualquier caso, si aprende todo sobre un lenguaje de programación orientado a objetos, pero nada sobre OOAD, creo que se ha perdido una oportunidad importante.

¿Problemas para superar?

Puente demasiado lejos? Si le pide a la gente que aprenda algo pequeño a la semana, en un año, entre las personas que participan, habrá muchos cambios. Si les pide que cambien todo lo que saben, será acogido con beneplácito por algunos, difícil para muchos e imposible para otros. Algunos cambios como el control de fuente están localizados. Tu transición de no hacerlo antes, tuviste un entrenamiento que no estaba estresando los límites de la memoria, alguien te guió a través de él la primera vez, y luego el día a día fue bastante fácil.

Otros cambios son generalizados. Por ejemplo, deshacerse de C y cambiar a Java requiere capacitación, configuración y grandes cambios en el día a día para adoptar un nuevo IDE, un nuevo compilador, un nuevo lenguaje, una nueva API, un nuevo modelo de implementación, etc. Este es el tipo de lo que ocurre con mayor frecuencia junto con un programa piloto o una reestructuración corporativa.

¿Liderando una revolución? Si las personas que actualmente realizan el trabajo tienen un historial de recompensas y la empresa no parece estar en peligro de fracasar, ¿cuál es su motivación para el cambio? Si pareces un extraño que quiere señalar la dirección y dejar que rindan cuentas por los resultados que no pueden predecir, puede parecer todo riesgo, no hay recompensa.

¿Poder de posición o liderazgo de ideas? Muchas organizaciones operan en función del poder de posición. Si le falta el apoyo visible de los gerentes, jefes de sección, directores y vicepresidentes, usted es simplemente un líder de ideas. Algunas personas están en la peligrosa posición de tener una idea y no poder entretener una segunda. Si puedes mostrarles en lugar de decirles, eso ayudará mucho a callar a los escépticos e interesar a los aliados talentosos.

¿Base de apoyo demasiado pequeña? Haz un triaje entre esas 250 personas y clasifícalas en tres categorías: listas para abrazar, dispuestas a aprender y no dispuestas a aprender. Tiene buenas razones para sentirse frustrado con algunas de las personas que no tienen interés en hacer un cambio. También podrías estar empujando una cuerda. Este es un esfuerzo perdido. Si tiene una idea de quién apoya el cambio, puede averiguar qué les interesa.

A diferencia de un triaje médico en el que la opción ética y práctica es ayudar al grupo intermedio que puede hacerlo con ayuda, usted puede invertir su energía y tiempo en función de su criterio y preferencia. Para su éxito, ¿por qué no cultivar el grupo que está listo para aceptar nuevas ideas? Pueden ser pocos al principio, pero como una bola de nieve, su visibilidad y credibilidad como defensor crecerán. Pronto la gente te preguntará cuándo será el próximo entrenamiento.

¿A largo plazo? Hasta que cultives un campeón para llevar las cosas detrás de ti, debes esperar invertir tiempo construyendo relaciones. Es posible que deba permanecer con los equipos que entrena durante más de un mes. Hasta que el equipo posea prácticas mejoradas para sí mismo, usted es solo un policía de tecnología o metodología. La tutoría es un proceso que puede llevar años. Hay muchas cosas que los desarrolladores no quieren hacer que crees que son importantes (creo que mencionaste específicamente las pruebas unitarias). Puede tomar un tiempo construir una visión compartida del valor que esto trae. Lo sé por experiencia porque una vez abogé por una herramienta de cobertura de código en una compañía de Fortune 500 que tenía una gran reputación de calidad, pero los gerentes y colegas por igual desconfiaban de comprometerse con ella.

¿Experto o de base? Mucho más rápido que la tutoría sería fomentar el apoyo de base que proviene de cada miembro del equipo. Comenzando con un equipo de diez especialistas en software, si tuviera la opción de tener a una persona trabajando en el proceso todo el tiempo o diez personas trabajando en el proceso el diez por ciento del tiempo, elegiría el segundo. El proceso de base permite a los defensores sentir el impacto del enfoque y adaptar el enfoque para resolver mejor los problemas del equipo que posee el trabajo.

¿Ves la línea de la libertad? Parte de la introducción de las "Mejores prácticas" es lograr que las personas renuncien a la libertad de hacer las cosas de una manera común. Renunciar a la discreción del programador será más agradable si busca oportunidades para dejar muchas opciones a los desarrolladores. Lo que eligen está delineado por lo que exige una partición que podemos llamar la línea de libertad. Puede ser necesario hacer divisiones similares y bien justificadas sobre prácticas organizacionales, regionales / específicas del sitio, de equipo y personales.

Esto debería haber sido un comentario, pero como aparentemente todavía no puedo comentar sobre cosas, podría ser una respuesta.

Lo más importante en este tipo de avances (ya sea OOP o cualquier otro cambio de paradigma, por ejemplo, programación funcional o lo que sea que salga en el próximo año) es REVISIONES DE CÓDIGO DE HACER Y PROGRAMACIÓN DE PAREJA . Acompáñalos, guía a los equipos hacia una forma diferente de hacer cosas que los ayuden.

Mi camino personal hacia la programación orientada a objetos comenzó cuando algunas evaluaciones aleatorias de código me castigaron por hacer cosas de forma modular y mantener el estado sin pasar por completo C ++ OO; pensar en código como

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(tenga en cuenta que clients_total puede ser completamente redundante, siendo un ejemplo particularmente mal planificado)

Y terminé haciendo esto solo cuando un compañero de trabajo mayor simplemente señaló mi pantalla y dijo "mira, si escribes lo mismo más de una vez, usa un procedimiento o una función y simplemente llámalo una y otra vez".

Las conversaciones y reuniones y las prácticas opcionales no harán que cambien de paradigma ni introduzcan una nueva práctica, ya que no hay un impulso real para hacerlo además de la pura curiosidad. Por otro lado, hacer que no hacerlo sea malo o que simplemente esté mal visto aumenta la tasa de adopción realmente bien.

Sin embargo, prepárese para el desarrollo quejumbroso y orientado a la clase que se producirá hasta que incorporen un diseño adecuado en lo que están haciendo. Verás muchas cosas que te harán morir por dentro un poco, pero así es como se ve el camino hacia el aprendizaje.