"Demasiado orientado a objetos"

Vengo de una sólida formación en OO, y recientemente comencé a trabajar en una organización que, aunque el código está escrito en Java, tiene mucho menos énfasis en un buen diseño de OO que el que estoy acostumbrado. Me han dicho que introduzco "demasiada abstracción", y que en cambio debería codificar la forma en que siempre se ha hecho, que es un estilo de procedimiento en Java.

TDD tampoco se practica mucho aquí, pero quiero tener un código comprobable. Enterrar la lógica empresarial en métodos privados estáticos en grandes "clases de Dios" (que parece ser la norma para este equipo) no es muy comprobable.

Me cuesta comunicar claramente mi motivación a mis compañeros de trabajo. ¿Alguien tiene algún consejo sobre cómo puedo convencer a mis compañeros de trabajo de que usar OO y TDD conduce a un código más fácil de mantener?

Esta pregunta sobre la deuda técnica está relacionada con mi pregunta. Sin embargo, estoy tratando de evitar incurrir en la deuda en primer lugar, en lugar de pagarla después del hecho que es lo que cubre la otra pregunta.

No te quejaste de que fuera imposible de mantener, solo que no era de tu agrado. Si es una elección de estilo deliberada, puede ser solo un caso de diferencias creativas irreconciliables, y debe ajustar su estilo para que se ajuste, o encontrar un lugar que se ajuste a su estilo preferido.

La gente puede y escribe código modular, eficiente, bien resumido, relativamente libre de errores en un estilo de procedimiento todo el tiempo. Java es una extraña elección de idioma para una tienda de este tipo, pero puedo ver que suceda si factores externos decidieron el idioma, como la necesidad de desarrollar para Android, por ejemplo.

Todos son genios. Pero si juzgas a un pez por su habilidad para trepar a un árbol, vivirá toda su vida creyendo que es estúpido. - Albert Einstein

Si fue una elección deliberada, realmente no puede juzgarlos por lo bien que se adhieren a los buenos principios de diseño orientado a objetos, debe juzgar por lo bien que se adhieren a los buenos principios de diseño de procedimiento y también refactorizar en consecuencia. Java no le permite escribir código fuera de una clase, por lo que la mera presencia de uno no significa que pretenden que un módulo esté orientado a objetos.

Por otro lado, si el código es un desastre en cualquiera de los paradigmas, probablemente debería reducir sus pérdidas.

Al leer su pregunta, recordé un consejo del programador Pragmatic.

Uno de sus consejos es Be a Catalyst for Change:

Es posible que se encuentre en una situación en la que sepa exactamente qué debe hacer y cómo hacerlo. Todo el sistema solo aparece ante tus ojos, sabes que es correcto. Pero solicite permiso para abordar todo y se encontrará con demoras y miradas en blanco. La gente formará comités, los presupuestos necesitarán aprobación y las cosas se complicarán. Todos protegerán sus propios recursos. A veces esto se llama "fatiga de arranque".

Es hora de cocinar sopa de piedra. Calcule lo que razonablemente puede pedir. Desarrollalo bien. Una vez que lo tengas, muéstrale a la gente y deja que se maravilla. Luego diga "por supuesto, sería mejor si añadiéramos ...". Finge que no es importante. Siéntese y espere a que comiencen a pedirle que agregue la funcionalidad que originalmente quería. A las personas les resulta más fácil unirse a un éxito continuo. Muéstrales un vistazo del futuro y conseguirás que se reúnan.

Entonces, creo que si comienzas a hacer un buen trabajo con tu conocimiento de OO y TDD, pronto comenzarán a buscar y preguntar sobre tu trabajo.

Para vender nuevas formas de trabajar, debe mostrar beneficios obvios. Escribir más capas de abstracción, sin un beneficio claro pero vago: "puede ser beneficioso para el futuro" no funcionará.

Haga fábricas donde las fábricas hagan más de un tipo de objeto. Use la inyección de dependencia, donde inmediatamente muestra beneficios. Haga interfaces que realmente serán implementadas por más de una clase.

Lo que veo con demasiada frecuencia en "OO verdadero" es que se utilizan técnicas avanzadas para resolver problemas realmente simples de una manera demasiado compleja.

¿Cómo puede mostrar el beneficio de una fábrica si solo va a hacer el mismo objeto? Encuentre un problema en su código que se beneficie de técnicas avanzadas y muestre su punto y trabajo desde allí.

Las guerras se ganan una batalla a la vez.

Solo puede convencerlos adoptando una pequeña porción de código e implementando TDD y mejores prácticas de OO para obtener los beneficios. Los has conducido a la tierra prometida, no solo muestra bonitas postales de ella.

Ciertamente, creo que hay casos de sobre abstracción en uso en muchas bases de código hoy en día. Solo ponga lo que necesita, y eso también incluye abstracciones.