Elija el esfuerzo de diseño de código o la pereza en el mundo del Banco

He trabajado durante dos años en un gran banco de inversión.

Realicé algunos proyectos técnicos con el deseo de crear el código más optimizado, respetando los buenos patrones de diseño adaptados, el principio SÓLIDO, la ley de demeter y evitando todo tipo de códigos duplicados ...

Cuando la entrega en producción => cero errores, todo ha sucedido como se esperaba.

Pero, la mayoría de los desarrolladores vinieron a mí para precisar que todo mi código es demasiado complejo para la comprensión de lectura. Escuché, por ejemplo: "haga un if y un instanceof, olvide el polimorfismo para que sea muy fácil corregir errores de producción de emergencia". No preferí responder ...

Sabiendo que estos desarrolladores no son curiosos en absoluto, se niegan a los esfuerzos para comprender un buen diseño (por ejemplo, el 90% de los desarrolladores no saben qué es un Patrón de Estrategia y hacen código de procedimiento y nunca lo diseñan porque quieren, dijeron, simplicidad ), mis gerentes de proyecto me dijeron que realmente estoy equivocado y que soy demasiado idealista para el mundo del Banco.

¿Qué me aconsejarías? Debo mantener el deseo de un código realmente bueno o adaptarme a la mayoría de los desarrolladores que son, lo repito, realmente no me interesa el código de diseño que es, según mi opinión, toda la belleza de nuestro trabajo de desarrollador.

O, por el contrario, ¿deberían aprender los principios básicos de OO y las mejores prácticas para adaptarse a mi código?

mis gerentes de proyecto me dijeron que realmente estoy equivocado y que soy demasiado idealista para el mundo del Banco.

GTFO!

Es hora de irse y compadecerse de ellos. ¿Por qué te importa una mierda? Sabes que a la larga les costará dinero con su personal incompetente. Este no es un juego de discusión técnica. Esto es sobre política. ¡Haga que capaciten a los otros desarrolladores o GTFO! Si no tienes suficiente peso político, ¡entonces GTFO! Busca una empresa con mejores prácticas.

La única razón para quedarse allí es una compensación adecuada para sus dolores de cabeza. ¡Entonces es mejor que paguen por encima del promedio o GTFO! Dudo que puedas crecer allí como desarrollador de software también. El crecimiento en nuestra profesión se logra principalmente trabajando con personas que son mejores que usted y que fomentan las mejores prácticas. Y cuanto mejor sea, mayor será su valor de mercado para las empresas que se preocupan.

Sí, sé que esta no es una de mis respuestas habituales, pero realmente, si no puedes jugar el juego de política en esta empresa, GTFO.

¿Qué me aconsejarías? Debo mantener el deseo de un código realmente bueno o adaptarme a la mayoría de los desarrolladores que son, lo repito, realmente no me interesa el código de diseño que es, según mi opinión, toda la belleza de nuestro trabajo de desarrollador.

No trabajaría para una empresa que quiere que brinde soluciones subóptimas. Quiero grabar mi nombre en el software. Quiero estar orgulloso de eso. No escribo aplicaciones de procedimiento en lenguajes basados ​​en el paradigma OO. ¡Creo en el software de alta calidad y si la compañía no lo hace, voy a GTFO! Espero que tengas suficiente "jódete dinero".

Situación difícil. Creo que puedes ir en dos sentidos en paralelo, manteniendo tu punto de vista y mostrando voluntad de compromiso:

• Esto se trata de dinero. Como cualquier trabajo de desarrollo, de hecho, pero dado que enfatiza el entorno bancario, esto debería funcionar aún mejor;). Muéstrales que tu estilo ahorra dinero. Encuentre un ejemplo de cómo un cambio en los requisitos podría hacerse realmente fácilmente debido a su diseño. Intenta encontrar otro código (debes asegurarte de no ser demasiado agresivo aquí, pero bueno, se trata de comparar estilos de código) que es propenso a romperse pronto, y muéstrales cómo no tienes que hacerlo. preocuparse por tales problemas porque su código es de mejor calidad para empezar.

• Esto se trata de dinero. ¿Qué pasa si su estilo de codificación de hecho cuesta dinero? Bien podría hacerlo, si otras personas pasan más tiempo tratando de entender su código que lo que se guarda con un diseño adecuado. Es posible que esté haciendo lo correcto técnicamente y aún así no contribuya positivamente al esfuerzo del equipo. Además, es posible exagerar el diseño de OOP. Estoy contigo en el lado del "buen diseño es hermoso", pero estoy tratando de hacerte consciente aquí de su punto de vista y de cómo pueden estar en lo cierto desde su perspectiva. Paralelamente al punto anterior, intente encontrar un lugar donde lo exageró. Eso te da algo de espacio para maniobrar: puedes decir, ok, puedo ser un poco más pragmático aquí y allá, pero mira, también hay lugares donde este código es realmente mejor.

Pero, la mayoría de los desarrolladores vinieron a mí para precisar que todo mi código es demasiado complejo para la comprensión de lectura

¿Se te ha ocurrido que pueden tener razón?

Trabajé con alguien que se esforzó mucho en escribir código que describió como elegante. Pasó mucho tiempo denunciando que el trabajo de otras personas no era elegante. Cuando es necesario mantener el código, su código no es el código que elegiría modificar. Es tan preciso y exigente que cambiarlo está profundamente lleno de peligros.

La palabra interesante que mencionas aquí es "compleja". El código que puede describirse como complejo rara vez puede describirse también como particularmente bueno.

Los fabricantes de muebles de la época victoriana (al menos, aquellos cuyo trabajo aún vemos hoy) eran verdaderos artesanos, lo que hicieron fue funcional, hermoso, bien diseñado y diseñado para durar toda la vida. Sin embargo, en los últimos 150 años, el mundo ha cambiado. No muchas personas están dispuestas a pagar por tal artesanía, cuando las alternativas más baratas son más comercialmente pragmáticas al comprar una mesa de comedor.

Muchos programadores quieren ser los artesanos de la antigüedad, desafortunadamente, el comercio dicta que esto no puede suceder todo el tiempo. Usted tiene la opción, adaptarse o irse. Hay empresas que quieren artesanos, pero son enormemente superadas en número por aquellas que desean productos que en su mayoría funcionan, baratos y ahora.

La sugerencia para mí de que no es adecuado para la mayoría del desarrollo de software comercial es "Cuando la entrega en producción => cero errores". Ni siquiera la NASA logró eso con los transbordadores espaciales.

Los únicos lugares donde es probable que preste atención a los detalles y, por lo tanto, al costo inicial, son los sistemas críticos de vida de nivel 1, por ejemplo, aviónica / aeroespacial, automotriz, militar y médico.

El problema es que estás trabajando en el lugar equivocado. Parece que eres un programador muy inclinado académicamente. No le irá bien en el entorno en el que se encuentra y es muy probable que se invente alguna excusa para deshacerse de usted y de su código "demasiado complejo". Es posible que se le asignen tareas no deseadas y / o se le den evaluaciones de bajo rendimiento hasta que se vaya por su propia cuenta o hasta que tengan un rastro de papel en la parte trasera suficiente para despedirlo.

Recomiendo que encuentre un lugar para trabajar que valore sus inclinaciones académicas. Están afuera También encontrarás algunos que están en el límite entre lo pragmático y lo académico. Un trabajo como ese puede ser su mejor opción, ya que le permitiría invitar a un poco de caos a su enfoque mientras ayuda a otros a controlarlo.

Antes de tomar medidas tan drásticas como cambiar de empleador, trataría de mejorar su propia capacidad de explicar a los no programadores como ustedes ejecutivos por qué su forma de codificación es mejor para la empresa y les ahorra tiempo y dinero. Y también, asegúrese de no aplicar patrones de diseño solo por los patrones de diseño: ¿está seguro de que también siguió las reglas de KISS y YAGNI? (De acuerdo, el patrón de estrategia y el polimorfismo no son ciencia espacial, deles a sus colegas algo de tiempo para adaptarse y explíqueles por qué elige ese enfoque).

En mi empresa, realizamos una serie de talleres basados ​​en Clean Code Developer . El propósito era crear un foro fuera del negocio cotidiano normal con sus frenéticos plazos y compromisos feroces, donde los desarrolladores pudieran aprender sobre principios de diseño de software (como usted mencionó), técnicas de programación, etc. y reflexionar sobre sus proyectos y su propio trabajo

También se discutieron ejemplos de la vida real de proyectos reales. Los comentarios de los participantes fueron AFAIK muy positivos. Sin embargo, es difícil medir un beneficio real.

La asistencia a esos talleres fue en parte por tiempo patrocinado por la compañía, en parte por el tiempo libre de los participantes. No llegará a aquellos colegas a quienes no les importa aprender y simplemente quieren hacer su trabajo e irse a casa, pero para cualquier otra persona que tenga algún interés en su propio trabajo, esto podría ser interesante.

Antes que nada, comprobaría que tu camino es realmente mejor. El código orientado a objetos puede ser muy agradable, pero también puede ser una pesadilla de efectos secundarios ocultos y cada acción puede requerir varias clases diferentes.

Mejor aún, vaya a InfoQ y vea la charla de Rich Hickey sobre "Simple Made Easy"

Tendrás que ceder un poco si quieres seguir trabajando allí sin problemas constantes. Un grupo de desarrollo que es todo de procedimiento no va a aceptar el polimorfismo de inmediato. Aunque es posible que no puedan diseñar de una manera OO, pueden aprender de su código. Pueden apreciar que algunos de sus códigos son más fáciles de mantener.

Como nota al margen, debe hacer preguntas durante el proceso de la entrevista para ver qué proceso de desarrollo y metodología de codificación se utiliza si cree que es importante hacer coincidir sus preferencias.

Las emergencias suceden. No somos perfectos y sus manos se echan a perder su código en algún momento. Eso a menos que nunca se tome un tiempo libre, lo que, como confirmará su médico de cabecera, no es bueno para su salud. Y conduce a mayores posibilidades de emitir un código pobre.

Su código puede tener una mayor calidad (hecho no comprobado) pero tienen políticas . (Seguro como el infierno hecho)

Se le advirtió que siga las políticas y será responsable de no haberlas seguido. En una situación de emergencia. En una aplicación bancaria. Quiero decir, si tu objetivo está terminando mal y en la cárcel puedo descubrir muchas formas más divertidas y significativas para obtener el mismo resultado.

Sin embargo, ustedes, compañeros de celda, estarán encantados de escucharlos divagar sobre la falta de curiosidad de sus antiguos compañeros de trabajo.

(una vez más, su empresa probablemente no tenga políticas internas contra el diseño OO, pero el torpe ingeniero entrenado por COBOL que tratará de arreglar su código inventará de la nada y, en mi humilde opinión, en el peor de los casos, él ' tendrá un 40% de probabilidad de anotar un golpe crítico)

Trate de recordar que la programación es considerada por algunos como un medio para un fin en lugar de por sí misma. Piense en todos los productos y servicios que utiliza: ¿pasa mucho tiempo considerando si el código que se encuentra debajo está hecho de manera elegante? ¿O simplemente los aprecias porque simplemente funcionan? Encuentre una industria o causa que le apasione, luego encuentre una organización con eso, luego ofrézcales soluciones que incluyan programación, pero no solo eso. Los problemas se pueden resolver de manera brillante de diferentes maneras.