¿Cómo puedo cumplir con mi exigencia de calidad personal en un entorno de baja calidad? [cerrado]

Fondo:

Estoy trabajando como desarrollador junior de Java. Mi objetivo profesional a largo plazo es convertirme en arquitecto de software.

Dicho esto, me exijo mucho a mí mismo para entregar un código de alta calidad.

Así que aquí está la historia detrás de mi pregunta:

Soy responsable de una gran refactorización en una parte central de nuestro sistema de compilación. Reuní los requisitos conocidos, los junté con lo que ya estaba codificado y tomé algunas decisiones de diseño de código. Los hice sin la ayuda de nuestro arquitecto de software senior, ya que quería que yo fuera completamente responsable del trabajo. Ya que llevo algunas semanas trabajando en esto, puedo decir claramente que lo volvería a hacer igual, lo cual es una señal positiva (¿o no?)

Sin embargo, después de la refactorización, se apresuraron con muchas funcionalidades nuevas, pensando que necesitaría algo de tiempo para agregarlas. Después de 3 días terminé mi trabajo y estaban realmente sorprendidos y ni siquiera pudieron darme un nuevo trabajo de primera mano.

Empecé a optimizar el código en cuanto a mantenibilidad, documenté la Arquitectura, etc.

El problema:

El arquitecto senior revisó mi código y no entendió el motivo de la elección de la arquitectura, pensó que estaba documentado y podía explicar todos los patrones que usé y por qué lo usé. Me dijo que mi código estaba 'demasiado a la moda de los libros de texto' con todos los 'patrones de diseño'. Continuó algo así como "no es necesario dividir las funcionalidades en clases, prefiero ver clases más grandes con muchas funcionalidades, por lo que no necesito buscar demasiados archivos".

Ahora la cosa es que él escribió la versión anterior de la herramienta que yo reescribí. Se dividió en 6 archivos, cada uno con alrededor de 2000 líneas de código sin documentación ni comentarios. En la versión refactorizada (antes de agregar todas las funcionalidades nuevas, que no pudo agregar a la anterior), había alrededor de 20 archivos con ~200-250 líneas de código (incluidos documentos y comentarios).

Si bien ahora puedo agregar una nueva funcionalidad dentro de 3 a 8 horas (probado) y puedo determinar en poco tiempo dónde ocurrió un error (normalmente los errores se solucionan dentro de 1 a 4 horas), me dice que estoy demasiado preocupado. sobre la Arquitectura. Tenga en cuenta aquí que hay ~ 150 archivos mientras tanto.

Mirando el código del gerente de desarrollo, los arquitectos senior y junior, me siento algo ofendido. No puede cambiar ninguna implementación sin romper todo el sistema (lo cual es posible por mi parte).

La pregunta:

Me siento muy incómodo escribiendo código que no cumple con mis exigencias personales de calidad, pero estoy seguro de que nunca podré cumplir con estas exigencias si empiezo a escribir código 'como los demás quieren que lo haga', así que estoy 'más rápido' (lo cual no es cierto, de lo contrario no habría razón para refactorizar todo el código).

No puedo encontrar ningún patrón de diseño dentro de todo nuestro código base, y nuestros arquitectos admiten que no saben nada sobre ellos. Ambos hechos me dan escalofríos, ya que carecemos de los elementos básicos, como Statepattern o Factories.

Entonces, ¿cómo puedo satisfacer mis propias demandas de calidad en esta situación? ¿Cómo puedo influir en la forma en que trabajan nuestros adultos mayores? Como tendré que trabajar y mejorar el código que escribieron los demás, ¿cómo podré hacerlo de alta calidad (a mi manera)?

EDITAR:

Algunos de mis compañeros de trabajo no 'senior' ya aplicaron cambios al código que escribí y se sorprendieron por la facilidad de hacerlo.

Mi atención se centró en proporcionar una arquitectura similar a un marco, donde todos pueden aplicar fácilmente las mejoras:

Para agregar otra funcionalidad, solo tiene que implementar UNA ÚNICA INTERFAZ que contenga una sola función.

No es necesario comprender la gran cosa que existe sin documentación, siempre que funcione.

En mi humilde opinión, creo que cuanto más fácil es usar una herramienta de este tipo, más complejo suele ser el fondo.

En definitiva, ¿una empresa diferente? Mientras tanto, hágales posible que usen su base de código, ¡fácilmente! Las personas son renuentes a aprender, especialmente bajo presión. Por lo tanto, haz que sea fácil para ellos usar tus cosas.
@gnat, no, esto no es un duplicado de esto
@PagMax Gracias por este artículo, le echaré un vistazo, pero a primera vista no diría que es un duplicado

Respuestas (1)

El mejor código es el código que todo el mundo entiende fácilmente.

Como tendré que trabajar y mejorar el código que escribieron los demás, ¿cómo podré hacerlo de alta calidad (a mi manera) ?

El "en mi camino" significa mucho aquí. Probablemente eres, o al menos dices ser, un excelente lobo solitario . Sin embargo, parece que no eres un jugador de equipo. Su código debe ser revisado y modificado fácilmente por otra persona, razón por la cual su superior tuvo problemas con su arquitectura.

Si quieres que las personas trabajen exactamente como tú quieres que trabajen, sé el jefe. Hasta que pueda convertirse en el jefe, cumpla con los estándares preferidos por su equipo.

Trate de ver esto desde el punto de vista de su Mayor. Él tiene que :

  • Lee tu código

  • Consulte las pautas varias veces

  • Lee el código de nuevo

  • Haz sus modificaciones de una manera a la que no está acostumbrado.

Esto es mucho de su tiempo senior . No le gustará, pero uno de sus objetivos es también ahorrar tiempo a los senior , incluso si cuesta más tiempo a los junior .

Ya que llevo algunas semanas trabajando en esto, puedo decir claramente que lo volvería a hacer igual, lo cual es una señal positiva (¿o no?)

Sin embargo, es posible que tenga una visión de túnel, tal vez se dirija en una dirección muy equivocada, pero está completamente seguro de que va en la dirección correcta. Como pareces un lobo solitario, es posible que desees obtener el consejo de alguien para asegurarte de que estás haciendo las cosas como debes.

Gracias por tu respuesta. Lo tendré en cuenta, pero echa un vistazo a mi edición.
Si bien su consejo es cierto para muchas situaciones (e incluso podría estar aquí, tendríamos que ver el código específico para estar seguros), el mismo peso del senior que describe el OP es una señal de alerta para mí. Insistir en tener archivos grandes para buscar no "tantos archivos" parece irrazonable desde cualquier punto de vista. Y no olvidemos que los seniors también cometen errores o no están calificados. El hecho de que sea "más fácil" para la persona mayor leer un archivo, no lo convierte en un requisito razonable.
Estoy de acuerdo con @dirkk. a mí me parece que el arquitecto puede sentirse amenazado por el OP. No creo que haya evidencia suficiente para etiquetar al OP como un jugador que no trabaja en equipo.