¿Trabajar con código heredado ayuda a uno a evolucionar como programador? [cerrado]
-
29-09-2020 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
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 desarrollar y me pregunto qué podría dar un proyecto así.
¿Consideraría que tratar con una aplicación grande y probablemente no tan bien escrita es una buena práctica para un principiante?
Solución
La solución de problemas del código existente es una excelente 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é diseñando.Si el código es bueno, aprenderá algo sobre cómo hacer una aplicación mantenible.
También aprenderá a lidiar con la complejidad de una aplicación comercial real.Dado que esto es en el sector bancario, aprenderá sobre cosas como la regulación federal y los controles contables internos en los que quizás nunca haya pensado.Estas son cosas buenas que debe saber cuando le piden 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 el hecho de que algo se haya escrito hace 15 años, en un idioma que preferiría no usar, no es necesariamente malo.Ha estado funcionando con éxito todo este tiempo después de todo.
Si, como ocurre con la mayoría de las aplicaciones heredadas, la aplicación no tiene pruebas unitarias, necesita estar realmente seguro de que un cambio no afectará otra cosa, puede aprender cómo agregar esas pruebas y cómo convencer a la administración de por qué es necesario agregar esas pruebas.una buena idea.
Otros consejos
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 y tratar de averiguar why el código fue escrito de esa manera.A veces es porque fueron 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 en el camino aprenderá lo que no debe hacer, lo cual 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 lo que es bueno y lo que es malo?Tal vez pueda reconocer los pros y los contras de los diferentes patrones/métodos, pero si fuera un desarrollador junior que recién comienza, es posible que no pueda hacerlo.
Y permanece demasiado tiempo en ese primer trabajo, y es posible que no estés aprendiendo o desarrollando suficientes habilidades y termines estancado allí.
Legacy puede significar cualquier cosa, pero según 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 se detenga y aprenda cada línea.
No creo que haya advertencias lo suficientemente claras contra el tipo de trabajos y proyectos que desvían tu carrera y te dejan atrapado en sumideros sin valor en este hilo hasta la fecha.
Alerta de analogía deportiva: ¿Crees que un linebacker 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 adquirieron las mejores prácticas y conocimientos y evitaron adquirir prácticas y actitudes que terminaron con su carrera.
Hay una gran cantidad de terribles códigos anti-patrones 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 de la que pueda presumir ante otros desarrolladores.Esto solo es relevante si su camino de crecimiento personal incluye ganarse el respeto de sus colegas ingenieros y no solo aumentar temporalmente los ingresos de cualquier empresa para la que trabaje (Suena mal, pero al final, la mejor ingeniería genera absolutamente la mayor cantidad de dinero en mi opinión).
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 ya es demasiado tarde.Quienquiera que haya intentado detener la deuda tecnológica o los antipatrones 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 corren el riesgo de chocar con 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 mucho tiempo para arreglarlo más tarde.Esto hace que las elecciones de trabajo para los futuros desarrolladores sean un asunto muy complicado.También señala los objetivos y mentalidades completamente diferentes entre los desarrolladores y las 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' costos y tiempo innecesarios.Dado que los ingenieros a menudo no saben cuál es el nivel de esfuerzo y tiempo hasta que se logra el estado final, el desarrollo de software se desarrolla como cualquier buen drama con personajes como ágil, scrum y kanban desempeñando papeles principales.
Una ventaja podría ser mantenerse alejado del código incorrecto hasta que haya visto suficiente código bueno para no estar 'corrompido'.Me encanta el dicho de que los desarrolladores senior crean soluciones simples para problemas complejos.Del mismo modo, los desarrolladores junior de nivel medio crean soluciones complejas para problemas simples y complejos.
Otra conclusión podría ser que necesita trabajar en código bueno Y malo en diferentes puntos para obtener comprensión.Si no ha hecho ninguna de las dos cosas, hágalo y prepárese para desaprenderlo todo cuando se encuentre con un sistema mejor.Creo que esta es probablemente una trayectoria más común para la mayoría de los desarrolladores.
Soy parcial este año porque siento que estoy escalando una montaña de 'salsa secreta' extremadamente complicada.Si bien aumentaré mi capacidad para 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, estoy avanzando a un ritmo constante y aceptando cada obstáculo en el camino como parte del curso.Después de haber revisado mis objetivos anuales con mi jefe, que incluyen desenterrar este agujero 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ómatelo con pinzas.¡Mañana podría amar el código heredado!(Dudo).
Depende mucho de cómo se defina "legado" en este contexto.Déjame darte un ejemplo de C y C++.Muchos programadores de C++ dicen que es una mala práctica usar cadenas C en aplicaciones C++, otros exigen que no se mezclen, mientras que otros, a su vez, afirman que es puro y completamente inútil usar fragmentos de código C porque son antiguos, es decir, "código "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 a un lado los problemas de rendimiento de los flujos y cadenas de C++ y algunas peculiaridades de STL, seguro que es una gran práctica echar un vistazo a lo que hay dentro de su tan querida directiva de preprocesador #include <string.h>. Si sigue el camino hacia la implementación y se encuentra en un unix/linux en /usr/include/string.h (y obtenga las fuentes de implementación de libc, por ejemplo, de gnu.org) y lea strcmp.c o strlen.c o strtok.c, apuesto a que escuchará la introducción gradual de "Qué hermoso mundo".
Sin embargo, hay una advertencia a 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 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 mucha gente que emplea Java y C# en el núcleo de entornos de baja latencia y alto rendimiento.No estoy de acuerdo con ellos, pero bueno, afortunadamente esto es asunto de ellos.Sin embargo, si hubieran usado HFT real, se habrían quedado muy atrás en la fila.Pero nuevamente, de esta oración se deduce fácilmente 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, sería invaluable como desarrollador.Es muy satisfactorio por cierto darme cuenta de lo mucho que has aportado.Iría por ello.
