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

23

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?

Mik378
fuente
19
Es difícil volar como un águila cuando trabajas con pavos ;-)
JonnyBoats
8
Cambia tu organización o cambia tu organización. - Martin Fowler
Don Roby
99
@ Mik378 Puede que tenga un problema de comunicación. Si documenta su código tan descuidadamente como escribió esta pregunta (y cuanto más OO "cruft" haya, más documentación necesitará, para que las personas sepan lo ITradeSettlementVisitorque se supone que debe hacer esta interfaz), sus pares tienen derecho a quejarse. Una cosa es escribir un código hermoso que te guste, otra muy distinta es estructurarlo y documentarlo de manera que sea accesible y utilizable por otros.
quant_dev
2
@quant_dev: Creo que estás asumiendo demasiado sobre Mik378. Su pregunta no me parece mal redactada; él no es un hablante nativo. No me gusta la verbosidad y el diseño de ingeniería excesiva en OO tanto como parece, pero la situación que describe Mik378 también suena a una campana: he trabajado con demasiados programadores que no podían entender cosas simples como expresiones booleanas (por lo que escriba "if (exp) then True else False") ... Es probable que este tipo de personas también se asuste por los patrones de diseño, el polimorfismo y, por lo tanto, vuelva al código de procedimiento antiguo.
Andres F.
2
Estoy totalmente en desacuerdo con que mantener el código simple y fácil de mantener para sus compañeros de trabajo es ser flojo, como se indica en el título.

Respuestas:

20

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".

Halcón
fuente
44
+1 - Una vez que se me ocurrió qué era GTFO ... ( urbandictionary.com/define.php?term=gtfo )
Reddog
2
@Falcon Estoy totalmente de acuerdo contigo y es un placer encontrar personas que compartan mi idea; y especialmente cuando dice: "El crecimiento en nuestra profesión se logra principalmente trabajando con personas que son mejores que usted y que fomentan las mejores prácticas". Lo más sorprendente y realmente frustrante es que soy el desarrollador más joven y realmente no aprendí de los más antiguos. Gracias por tu respuesta :)
Mik378
+1, estoy completamente de acuerdo. Este banco simplemente no parece un buen ambiente de trabajo, y sus problemas parecen insuperables: malos programadores, mala administración. GTFO de hecho!
Andres F.
2
@ Mik378: Su empleador actual no puede usar completamente sus habilidades y, en consecuencia, no podrá pagarle lo que vale. Una mejor organización podrá obtener más valor de usted y puede pagarle más.
Kevin Cline
+1, si pudiera darte más votos a favor, obtendrías 1000 de mí. Después de haber trabajado en un banco de inversión, sé exactamente a qué se enfrenta Mik378. Es un caldo de cultivo para el comportamiento tóxico, los respondedores de polaridad y la egomanía. No es un ambiente ideal para promover la excelencia técnica.
Desolate Planet el
18

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.

Nicolas78
fuente
Gracias por su respuesta desarrollada. He tomado nota de su consejo :)
Mik378
Agregaré a esto el simple problema de FizzBuzz. Escríbalo en Java y luego hágalo nuevamente de forma TDD, de repente se vuelve ilegible, ¿no es así ;-).
Martijn Verburg
@Martijn Verburg - ¿Crees que TDD conduce a un código ilegible?
Don Roby
@Don Roby - a veces sí, especialmente cuando se trata de algo como FizzBuzz en un idioma OO
Martijn Verburg
+1 @ Nicolas78 "Además, es posible exagerar el diseño de OOP", por ejemplo, hacer tipos de datos primitivos Objetos como int, por ejemplo.
therobyouknow
16

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.

temptar
fuente
1
+1000 De acuerdo. El código es para humanos. La advertencia es, por supuesto, que los otros codificadores deberían poder leer lo que la mayoría de los codificadores escriben. Cualquier persona que no entienda lo básico debe mejorar.
Iain Holder
3
+1 @temptar para "¿Se te ha ocurrido que pueden tener razón?" y "El código que puede describirse como complejo rara vez puede describirse también como particularmente bueno".
therobyouknow
2
-1: No creo que tengan razón, solo un poco mayor, y creo que una lectura más cercana de la pregunta lo hace obvio. La frase clave del OP es "evitar todo tipo de códigos duplicados ..." Está tratando de SECAR el código, pero hacerlo requiere una sofisticación que aparentemente carecen de sus colegas. También citó las sugerencias de sus colegas para "simplemente agregar un if ... instanceof". Eso también me dice que el OP está en el camino correcto, y sus colegas están construyendo un gran WTF.
Kevin Cline
lo que me preocupa es que la POO "demasiado compleja" puede ser algo bueno, pero también puede volverse muy compleja muy rápido. Sospecho que el Cartel original puede haber bebido la ayuda fría de OOP y no ha entendido que no siempre es la mejor manera de codificar, y que puede estar introduciendo una gran complejidad adicional donde no es necesario.
Zachary K
Parece que este compañero de trabajo tuyo no tiene sus pruebas establecidas para el mantenimiento futuro. Es posible que desee mencionarlo con el gerente del proyecto.
10

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.

Mattnz
fuente
1
+1 @mattnz para "Usted tiene una opción, adaptarse o irse"
therobyouknow
2
No estoy de acuerdo, este es un banco . Tienden a gustarles que no haya errores en su software ya que los errores pueden ser bastante caros. También las soluciones pueden funcionar durante años o décadas.
2

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.

jfrankcarr
fuente
+1 @jfrankcarr por la astuta observación de "se le pueden asignar tareas basura" (una forma de despido constructivo)
therobyouknow
2

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).

Doc Brown
fuente
Estoy de acuerdo, el problema es que no quieren aprender, no quieren cambiar su mentalidad (no soy un genio en Java, pero cuando no entiendo algo que la mayoría de la gente considera algo excelente para saben, haré un esfuerzo para aprenderlo (libros, artículos de internet, stackoverflow, etc.). En resumen, no quieren tener dolor de cabeza con los patrones (digo patrón pero podría decir el principio de programación "Excelente" más en general) que no les trae mucho más dinero ... Es difícil decir eso, pero es tan cierto. Si solo la aplicación funcionara bien => Seguramente no escribiría este tema.
Mik378
@ Mik378: estás hablando mucho sobre lo que "los demás hacen mal". ¿Seguro de que todo lo que hiciste estuvo bien?
Doc Brown
El polimorfismo de @DocBrown tiene la clara desventaja de fragmentar la lógica en los archivos donde las instancias simples lo mantienen en un solo método. ¿Quizás las unidades de trabajo son demasiado pequeñas?
2

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.

Robert Petermeier
fuente
Me gusta mucho esta idea.
temptar
2

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"

Zachary K
fuente
1

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.

JeffO
fuente
0

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)

ZJR
fuente
1
Personalmente, creo que un desarrollador muy bueno hace un código excelente tan rápido como un código sucio. Estoy de acuerdo con usted en el aspecto de la emergencia ... pero cuando un proyecto se planifica durante 4 meses, y los desarrolladores ni siquiera tienen una visión global de lo que harán, cómo y si ya existe algo en la aplicación que ayudarlos, no pude aceptarlo. Cuando un desarrollador dice: "Sé que este código es horrible, pero nunca lo refactorizaré porque puedo romperlo", es ridículo. ¿Son ingenieros o no? Un ingeniero debe tomar riesgos y hacer algunas pruebas reales buena unidad para ser Confiant
Mik378
1
Estaría de acuerdo si no estuviéramos hablando de bancos aquí. Siempre siento que son un grupo diferente de los otros programadores. También suelen ser mayores. (En mi entorno, como mínimo, como en todas partes, deduzco) Sus matemáticas son simples, pero su precisión no lo es.
ZJR
@ZJR Te estás dejando llevar aquí, con tus profecías de que el OP está en la cárcel por usar OO. La mayoría del código bancario no está sujeto a tal escrutinio.
quant_dev
0

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.

therobyouknow
fuente