¿Tratar con código heredado ayuda a uno a evolucionar como programador? [cerrado]

Soy un desarrollador de Java con un poco más de un año de experiencia, lo que me coloca en algún lugar por encima de un junior, pero aún no entre los desarrolladores de nivel medio. Recientemente me ofrecieron un proyecto a largo plazo que consiste en estudiar un código de aplicación bancaria existente durante 4 meses y luego introducir cambios cuando sea necesario. Como programador no tan experimentado, estoy buscando formas de desarrollarme y me pregunto qué podría aportar ese proyecto.

¿Consideraría tratar con una aplicación grande y probablemente no tan bien escrita como una buena práctica para un principiante?

La resolución de problemas del código existente es una súper forma de desarrollarse como programador. Si el código es malo, aprenderá el impacto de los errores que cometieron y tal vez evite algunos de ellos cuando esté haciendo el diseño. Si el código es bueno, aprenderá algo sobre cómo hacer una aplicación que se pueda mantener.

También aprenderá a lidiar con la complejidad de una aplicación comercial real. Dado que esto se encuentra en el sector bancario, aprenderá sobre cosas como la regulación federal y los controles internos de contabilidad que quizás nunca haya pensado. Estas son cosas buenas que debe saber cuando se le pide que diseñe algo más en el mundo financiero. Y la programación financiera puede ser un sector bastante lucrativo para trabajar, por lo que obtener experiencia bancaria puede ser muy bueno para usted.

Incluso puede aprender que solo porque algo fue escrito hace 15 años, en un idioma que preferiría no usar, no es necesariamente malo. Se ha estado ejecutando con éxito todo este tiempo después de todo.

Si, como con la mayoría de las aplicaciones heredadas, la aplicación no tiene pruebas unitarias, necesita asegurarse de que un cambio no afecte a otra cosa, puede aprender cómo agregar esas pruebas y cómo vender a la administración sobre por qué agregar esas pruebas es una buena idea.

Creo que es una excelente práctica para un principiante cualquiera. Aprender de la experiencia de otros puede ser muy efectivo.

El verdadero desafío no es encontrar errores, sino meterse en la cabeza del otro desarrollador e intentar descubrir que whyel código fue escrito de esa manera. A veces es porque eran descuidados, y otras porque tenían una muy buena razón. Suponga que el desarrollador fue al menos tan bueno como usted, pero puede haber tenido más conocimiento del dominio.

Esta es una buena práctica para cualquier desarrollador en cualquier momento de su carrera. Si puede revisar y analizar el software existente y encontrar formas de mejorarlo, demostrará que es un desarrollador valioso. No solo aprenderá cómo otros han diseñado y desarrollado software, sino que a lo largo del camino aprenderá lo que no debe hacer, que es un conocimiento valioso en sí mismo.

Si está preparado para el desafío, tome este proyecto de frente y hágalo mejor.

Te ayudará absolutamente, pero debes tener cuidado.

Debe asegurarse de aprender del código heredado. ¿Cómo sabes qué es bueno y qué es malo? Tal vez pueda reconocer los pros y los contras de diferentes patrones / métodos, pero si fuera un desarrollador junior recién comenzando, es posible que no pueda hacerlo.

Y quédese demasiado tiempo en ese primer trabajo, y es posible que no esté aprendiendo o desarrollando suficientes habilidades y termine atrapado allí.

Legacy puede significar cualquier cosa, pero en base a su comentario 'no tan bien escrito', voy a suponer que Legacy significa tecnologías y patrones 'malos' o al menos 'desactualizados'. Si el código heredado es bueno, no te detengas y aprende cada línea de él.

No creo que haya advertencias lo suficientemente claras contra el tipo de trabajos y proyectos que desvían su carrera y lo mantienen atrapado en valiosos agujeros en este hilo hasta la fecha.

Alerta de analogía deportiva: ¿Crees que un patrocinador de línea en la NFL aprende más y se vuelve más valioso al jugar en el equipo con el peor récord o el mejor? Mi respuesta: no solo son más valiosos por haber jugado para los mejores equipos, sino que probablemente recogieron las mejores prácticas y conocimientos y evitaron recoger las prácticas y actitudes de fin de carrera.

Existe una gran cantidad de códigos antipatrones terribles que realmente funcionan para el negocio y pagan muchos salarios de desarrollo. Propongo que un desarrollador que no haya visto suficiente código hecho de la manera 'correcta' podría confundir el código antipatrón con una solución legítima a un problema. La empresa puede decir que la solución funciona, pero no es una que desee en su currículum o una que presumiría ante otros desarrolladores. Esto también es relevante si su camino de crecimiento personal incluye ganarse el respeto de sus colegas de ingeniería y no solo aumentar temporalmente los ingresos de cualquier empresa para la que trabaje (suena mal, pero al final, la mejor ingeniería absolutamente gana la mayor cantidad de dinero IMO) .

Desafortunadamente, hay mucho código y mucho tiempo que puede pasar antes de que se revele la deuda tecnológica. Y esa deuda tecnológica generalmente se reconoce exactamente cuando es demasiado tarde. Quien haya tratado de detener la deuda tecnológica o los patrones anti antes, podría haber sido dejado de lado debido al gasto adicional percibido o la falta de comprensión de la escalabilidad, etc. Es nuestro deber como ingenieros exponer la deuda tecnológica de inmediato. Los proyectos sin ingenieros experimentados están en peligro de golpear una pared de ladrillos en algún momento, en realidad todos los proyectos incluso con desarrolladores talentosos. La mayoría de las empresas ven "algún punto" como tiempo de sobra para arreglarlo más tarde. Esto hace que las elecciones de trabajo para los desarrolladores emergentes sean un asunto muy complicado. También señala los objetivos y mentalidades completamente diferentes entre desarrolladores y empresas y lo complicado que es cerrar la brecha.

El objetivo de los ingenieros es 'incluir' el trabajo científico real y la consideración del diseño, mientras que el objetivo de las empresas es 'excluir' el costo y el tiempo innecesarios. Dado que los ingenieros a menudo no saben cuál es el nivel de esfuerzo y tiempo hasta que el estado final se realiza, el desarrollo de software se desarrolla como un buen drama con personajes como ágil, scrum y kanban como protagonistas.

Una conclusión podría ser mantenerse alejado del código incorrecto hasta que haya visto suficiente código bueno para no ser 'corrompido'. Me encanta el dicho de que los desarrolladores senior crean soluciones simples para problemas complejos. Del mismo modo, los desarrolladores de nivel medio junior crean soluciones complejas para problemas simples y complejos.

Otra conclusión podría ser que necesita trabajar en un código bueno Y malo en diferentes puntos para obtener comprensión. Si no lo ha hecho, entonces hágalo y prepárese para desaprender todo cuando encuentre un sistema mejor. Creo que esta es probablemente una trayectoria más común para la mayoría de los desarrolladores.

Este año soy parcial porque siento que estoy escalando una montaña extremadamente complicada de 'salsa secreta'. Si bien aumentaré mi capacidad de descifrar algunos de los peores patrones que he visto, es tan 'personalizado' y 'único' que no creo que mi lucha aumente mi comerciabilidad o mi conjunto de habilidades utilizables en mi futuro.

Para mantener mi cordura, solo estoy avanzando a un ritmo constante y abrazando todos los bloqueos de la carretera como parte del curso. Después de haber revisado mis objetivos anuales con mi jefe que incluyen la excavación de este hoyo heredado, estoy pensando que podría ser una escalada de sacrificio. Podría sobrevivir al proceso con malas críticas y lentitud percibida. Esta es una advertencia realista y premonitoria para aquellos de ustedes que se preguntan qué trabajo tomar.

Descargo de responsabilidad: esta publicación durará mucho más que mis opiniones, así que tómala con un grano de sal. ¡Mañana podría amar el código heredado! (Dudo).

Depende mucho de cómo defina "legado" en este contexto. Déjame darte un ejemplo de C y C ++. Muchos programadores de C ++ consideran que es una mala práctica usar cadenas de C en aplicaciones de C ++, otros no exigen mezclarlos, mientras que otros, a su vez, afirman que es puro y completamente inútil usar bits de código C porque son viejos, es decir, " "heredado". Algunos van más allá y evitan el uso de modismos estándar anteriores a C ++ X (reemplace la 'X' con el número apropiado), estilo, es decir, sintaxis, por su estilo "heredado".

Dejando de lado los problemas de rendimiento de las secuencias y cadenas de C ++ y algunas peculiaridades de STL, es una buena práctica echar un vistazo a lo que hay dentro de su querida directiva de preprocesador #include <string.h>. Si sigue la ruta de la aplicación y se encuentra en una máquina Unix / Linux en /usr/include/string.h(y obtener fuentes de implementación de libc, por ejemplo, de gnu.org ) y leer strcmp.co strlen.co strtok.c, apuesto a que vamos a escuchar "lo que un mundo hermoso "introduciéndose progresivamente.

Sin embargo, hay una advertencia para esta prosa, a saber, clases y métodos obsoletos. En Java todavía se puede acceder a muchas cosas heredadas desde un entorno reciente, pero si no recuerdo mal, no todo. En el sector del IB, desde mi propia experiencia, bueno, no todo el software está escrito por buenos programadores. Muchos graduados habían tenido una exposición prácticamente nula a la programación del mundo real antes de comenzar en un puesto de analista / desarrollador. Pero no generalices esta afirmación. Conozco a muchas personas que emplean Java y C # en el núcleo de entornos de alto rendimiento y baja latencia. No estoy de acuerdo con ellos, pero bueno, afortunadamente es asunto suyo. Sin embargo, si se hubieran vuelto HFT reales, se verían empujados hacia atrás en la línea. Pero otra vez, Se deduce fácilmente de esta oración la suposición (y en muchos casos el hecho) de que el código Java es altamente optimizable. Y si puede sobresalir en la optimización, si es necesario, no solo arreglando esto o aquello, se volverá invaluable como desarrollador. Por cierto, es muy satisfactorio darse cuenta de cuánto ha contribuido. Yo iría por ello.