Recientemente comencé a trabajar como desarrollador para una nueva empresa. Tengo un poco más de dos años de experiencia en programación (universidad + pasantías), y en este nuevo trabajo me pidieron que hiciera algunas mejoras en las funciones y todo el código base es un desastre. Estoy señalando algunas dificultades técnicas que enfrento como contexto para mi pregunta. Cualquier desarrollador razonable debe estar de acuerdo en que algunos de estos son molestos.
Cuando se asignan nuevas funciones o errores, me resulta extremadamente difícil depurarlos, ya que prácticamente todos los errores se suprimen y se imprimen como registros; como resultado, termino dedicando más tiempo a entregar lo que se espera de mí. El programa nunca se rompe. Todas y cada una de las excepciones se capturan y silencian como registros. Por lo tanto, no hay forma de encontrar dónde ocurre un error sin ensuciarse (usando llamadas de "rastreo", etc.), lo cual no es realmente necesario si las excepciones se manejaron juiciosamente.
lo que he probado
Intenté pedir ayuda internamente, obviamente. La respuesta está ahí, pero la mayoría de las veces es algo como "Depurar y encontrar la diferencia", pero la depuración no es realmente útil, como expliqué anteriormente.
Hablé con mi gerente y su respuesta fue que puedo reescribir este código base con un tiempo, pero entrego lo que se espera antes de comenzar la reescritura, lo que nuevamente viene al grano: no puedo descifrar este código de espagueti. Si pudiera, ni siquiera tendría que volver a escribir.
¿Por qué es esto un problema?
No puedo completar las cosas a tiempo, por lo que no estoy rindiendo tanto como quisiera. Esto afectará mi crecimiento y es posible que me despidan por no ser puntual. Estoy empezando a odiar mi trabajo como resultado de esto, no poder escribir código, porque no quiero perder tiempo depurando un desastre.
Otra información
De ninguna manera soy un desarrollador veterano. Paso parte de mi tiempo respondiendo (también haciendo) preguntas sobre Stack Overflow y tengo una idea bastante clara de cómo se ve el código bueno y malo. No tengo experiencia como desarrollador profesional aparte de unos pocos meses (pasantías aparte), por lo que no sé si esto es algo normal.
Avíseme si necesita información adicional.
Actualizar
Habiendo tenido en cuenta las respuestas que he recibido aquí, seguí adelante y hablé con las personas que escribieron esto y su última respuesta es (no literal)
"Cambie según las necesidades actuales. Ahora es el propietario de este código base. Haga lo que quiera para que funcione".
Esto se siente como si estuvieran aliviados de que ya no sea su (problema).
Mi gerente estuvo de acuerdo en dejarme reescribir el código, pero solo después de completar mi trabajo pendiente actual, lo que supongo que es una solicitud sensata de su parte.
Una gran cantidad de código heredado apesta. Incluso si el código se desarrolló utilizando las mejores prácticas en ese momento, las mejores prácticas de hace diez años a menudo son bastante diferentes de las mejores prácticas de hoy. Pero más que eso, a medida que los desarrolladores van y vienen, no todos los desarrolladores se adherirán a la visión original que tenía el desarrollador original. Incluso si son capaces de descubrir esa visión, es posible que no les importe avanzar más. A algunos desarrolladores les puede importar, pero otros pueden simplemente implementar trucos rápidos y feos para hacer el trabajo. Después de unos años de esto, puedes tener una base de código realmente fea.
Mi consejo sería tratar de mantenerlo. Si huye de un trabajo cada vez que encuentra un código basura, estará huyendo de todos los trabajos bajo el sol. Bueno, tal vez a excepción de las nuevas empresas de campo verde. Si te acostumbras a trabajar con código basura ahora, entonces tus experiencias pueden ser historias que compartirás en entrevistas más adelante.
El "código heredado de soporte" es una gran parte de la industria, con diferentes niveles de fealdad. Si decide que no está de acuerdo con trabajar en esa parte del campo, entonces sí, puede irse y buscar otro trabajo, pero debe darse cuenta de que está recortando mucho del posible espacio profesional. Si generalmente está de acuerdo con el código heredado, pero cree que este código heredado en particular es excepcionalmente feo y no quiere lidiar con esto específicamente. Bueno, puede que tengas razón. Sin embargo, no apostaría necesariamente por ello.
Parece que tendrá que trabajar en la refactorización sobre la marcha. No parece probable que su jefe le ofrezca la oportunidad de realizar refactorizaciones importantes en el corto plazo, pero no impedirá que mejore el código que toca. Una vez que descubras lo que está haciendo un fragmento de código, coméntalo. Si está tocando una parte del código y ve esos envoltorios de "tragar todos los errores", considere dónde puede darse el lujo de hacerlos más informativos. Incluso si los mantiene ejecutándose en los registros, puede volcar todo el seguimiento de la pila allí, momento en el que debería ser relativamente sencillo obtener la información que necesita de todos modos. A medida que comprendas mejor las cosas, trabaja para mejorar donde puedas.
En lo que respecta a "completar las cosas a tiempo", ¿es solo su percepción o está recibiendo algún tipo de retroalimentación de sus jefes de que consideran que su trabajo es inaceptable? Es cierto que se necesita más tiempo para trabajar con el código heredado con mucha deuda de código, especialmente cuando recién comienza. Es posible que ellos estén tomando esto en cuenta y tú no. Esto probablemente mejorará a medida que obtenga una comprensión más profunda de cómo funciona el sistema (y logre refactorizar parte de él). ¿En cuanto a "afectar su crecimiento"? Bueno... sí, pero no como estás pensando. No afectará si creces o cuánto creces. Afectará tu forma de crecer. Como dije, administrar el código heredado es una gran parte de la industria. Aprender a hacerlo bien no es crecimiento desperdiciado.
Learning how to do it well isn't wasted growthEl código heredado compone la mayor parte del desarrollo en el mercado. Rara vez se llega a desarrollar nuevos proyectos desde cero con herramientas y prácticas de última generación.
El código heredado no es malo en sí mismo, pero sigue siendo un hecho bastante común que necesita aprender a trabajar en dicho entorno.
No estoy diciendo que debas aguantarte y apegarte a ello, sino que debes dejarle una oportunidad a tu lugar de trabajo. Debe aprender a abordar el código heredado (por ejemplo, puede leer "Trabajar de forma efectiva con el código heredado") y debe enseñar a su colega y gerente sobre el costo del código incorrecto.
Si puede enseñar a las personas mejores prácticas e introducir buenas prácticas y herramientas en su lugar de trabajo, obtendrá valiosas habilidades profesionales y credibilidad. Sin embargo, si la situación no mejora y usted la sufre, busque otro lugar de trabajo.
Seguiría trabajando. Haga lo mejor que pueda con el código base tal como está, pronto entenderá cómo funciona.
A medida que trabaja en los elementos, limpie el código lo mejor que pueda en las áreas en las que está trabajando. Después de un tiempo, debería poder liberar algo de tiempo para un trabajo más amplio.
Pero por ahora, aumente y ajuste según sea necesario. Trata esto como una experiencia de aprendizaje.
Además, si te fuiste y encontraste otro trabajo, la probabilidad de que termines en un equipo que usa una base de código fabulosamente organizada es mínima. El código perfecto es un ideal, pero siempre habrá un compromiso entre la perfección y "hacerlo". La mayoría de las veces "hazlo" gana.
Como dijeron otros, hay un montón de código de mierda por ahí, y muchos de nosotros terminaremos manteniéndolo.
(También es justo decir que somos nosotros quienes lo creamos, bajo presión, o al comienzo de nuestras carreras, o porque no sabemos nada mejor. ¡No se lo tome como algo personal cuando otros le imponen ese código! )
Sin embargo, sus elecciones al principio de su carrera son importantes. mucho _ Si pasa sus primeros trabajos haciendo el mantenimiento de algunas aplicaciones de código espagueti, será difícil desarrollar sus habilidades de ingeniería más finas. Será difícil aprender un buen diseño. Y reconocer malos diseños no es lo mismo que saber crear buenos.
En mi experiencia, esto obstaculizará sus oportunidades profesionales más adelante. Estoy entrevistando a muchos ingenieros de software y he rechazado puntajes por esta misma razón. Son amables, amigables y conocen la programación básica, pero después de años de trabajar en un mal ambiente, no parecen ver más allá de eso. No saben cómo resolver bien los problemas. Después de que les dijeran muchas veces que las cosas no pueden cambiar (o cambiar, pero lentamente), perdieron la chispa. Sus soluciones de ingeniería preferidas estarán influenciadas por su (mala) experiencia.
Cuando un recién graduado carece de mejores habilidades, un gerente de contratación busca la capacidad de aprender. Cuando alguien con 5 o 10 años de experiencia carece de esas habilidades, es una gran señal de alerta. ¿Por qué no aprendieron todavía? ¿Lo harán alguna vez? ¿Son entrenables?
Ser exigente con sus trabajos al principio de su carrera limitará sus opciones. No ser exigente también limitará tus opciones (y tu salario) más adelante.
En cuanto a qué buscar en este u otros trabajos. No es tanto la tecnología lo que importa, sino los mentores. Encuentre un lugar donde haya alguien de quien realmente pueda aprender y luego péguese a él o ella. Aprenda todo lo que pueda antes de pasar a la siguiente oportunidad.
Tu escribiste:
Hablé con mi gerente, su respuesta es que puedo reescribir este código base con un tiempo, pero entrego lo que se espera antes de comenzar la reescritura, lo que nuevamente viene al grano, no puedo descifrar este código de espagueti, si puedo lo haría ni siquiera tienes que reescribir
Esto suena como un caso ideal para "refactorizar" gradualmente la base de código.
Mientras realiza sus tareas diarias, aproveche la oportunidad de "refactorizar" (mejorar) la base de código. Comience, por ejemplo, a mejorar el manejo de excepciones. Luego agrega comentarios. Luego mejore el manejo de consultas. Luego mejorar algo más, y así sucesivamente.
Hable con su gerente, hágale saber su ambición de hacer esto y mezcle el trabajo de "refactorización" con sus tareas diarias. Convénzalos de que la refactorización generará dividendos a mediano y largo plazo, dado que será más fácil trabajar con una mejor base de código, tanto para usted como para el próximo programador (sea quien sea).
Con el tiempo, el código base mejorará y, algún día, estará organizado de forma lógica y clara.
Como programadores, todos tenemos que lidiar con código incorrecto de vez en cuando. ¡No se asuste ni se desanime, tome esto como un desafío y una actividad de aprendizaje!
Entonces, bienvenido al mundo actual del desarrollo de software, no al mundo como a usted le gustaría que fuera. En el mundo, como me gustaría que fuera, todo el código estaría muy comentado, tendría planes de prueba adecuados, diseños, especificaciones de requisitos y muchas otras cosas.
He estado en esto durante 42 años por dinero, todavía no obtengo lo que quiero.
Esto se adapta más a la situación en la que te encuentras.
Hasta que no tenga suficiente experiencia, que estará mucho más cerca de los 10 años de los que tiene, no tendrá la reputación profesional para hacer que las organizaciones cambien. Lo que puede hacer ahora, al comienzo de su carrera, es comenzar a desarrollar esa reputación. Eso significa:
El tipo de problemas que estás describiendo son algo que lleva años solucionar. Por un lado, hay una gran cantidad de código heredado que se pudrió a lo largo de los años. Por otra parte, tienes que conseguir que tus compañeros de trabajo se sumen a la idea.
Pero lo que no puede hacer, si quiere tener un buen código para trabajar, es salir. Porque es igual de malo, más o menos, en el siguiente lugar.
Lo más importante primero: No, esto no es algo normal. He trabajado más de 15 años como desarrollador de software, en una startup (en el Reino Unido), un departamento gubernamental (en Nueva Zelanda), una gran institución de investigación, una institución de telecomunicaciones e inversión de miles de millones de dólares (todo en Suiza). Ninguno de ellos tenía ni cerca de este código malo. Claro, encontré todos estos problemas (no la parte del "90%", sino todos por separado) más de una vez, y el código no idiomático en particular es bastante común, pero una base de código llena de todos ellos es un trampa de muerte.
Un gerente que se precie sabrá que las reescrituras son muy arriesgadas y bastante costosas, incluso cuando van muy bien. En una startup, sería ingenuo esperar que una reescritura esté en algún lugar dentro del horizonte financiero de la empresa.
En cuanto a si debe quedarse, hay montones de trabajos en los que obtiene la capacitación adecuada, donde las personas realmente se preocupan por cosas como la calidad y la seguridad, donde los gerentes son realistas y honestos acerca de las reescrituras, donde puede recurrir a personas con un conocimiento íntimo de la sistema existente en busca de ayuda y, si tiene un poco de suerte, todo lo anterior.
Tener que trabajar con un código base antiguo no es un problema en sí mismo. Alguien tiene que hacerlo. Al igual que alguien tiene que recoger la basura de las personas una vez por semana o cada dos semanas. Por supuesto, si no te gusta, deberías encontrar un trabajo diferente.
El problema relacionado con el lugar de trabajo puede ser que su trabajo no sea valorado. Solo produce costos para la empresa, no nuevos ingresos. Y como dijiste, produce menos resultados a la semana de lo que podría en cualquier otra posición. Pero debe quedar claro para su gerente y la gerencia en general que debe recibir un pago por el trabajo que realiza, no por la cantidad de ganancias que genera en los bolsillos de la empresa. (Y si solo produce costos, no nuevos ingresos, supongo que causaría un gran daño si no se hiciera ese trabajo, o no lo habrían contratado en primer lugar. Generar ganancias y evitar pérdidas es lo mismo. O deberíamos deshacernos de los bomberos en las ciudades de todas partes, ya que nunca producen nada de valor. Por lo general, cuando hacen su trabajo, hay pérdidas masivas. Si no hacen su trabajo, habría pérdidas mucho más masivas.
Así que déjele claro a su jefe que (a) el código base está desordenado y que no está documentado, y que cualquier trabajo en él toma más tiempo de lo esperado, y (b) su pago debe ser igual o mejor que la de las personas que hacen los trabajos elegantes.
Dependiendo de cuánto tiempo se espera que se mantenga este producto, llegue a un acuerdo con su gerente de que es parte de su trabajo mejorar y documentar la base de código.
Parte de esto está en ti. Al entrevistarse para un trabajo, especialmente un trabajo de programación o ingeniería, algunas de las preguntas que debe hacerse son:
Etc.
Asegúrese de hacer estas preguntas durante el proceso de la entrevista. Ninguna empresa es perfecta, pero hay muchas empresas/bases de código que agotan tu alma.
Si no está satisfecho, aguante durante 6 meses a un año. A nadie le gusta escuchar que renuncié a mi último trabajo porque el código base era terrible. Todavía podría aprender algunas cosas sobre lo que NO debe hacer, y es posible que pueda realizar pequeñas mejoras durante su mandato sobre las cuales le preguntará su futuro empleado.
La pregunta clave es:
¿Su gerencia comprende, reconoce y asume el problema, y maneja sus propias expectativas con respecto a la eficiencia y la calidad del trabajo en función de esa base de código?
En caso afirmativo: vea esto como una oportunidad.
Si no: Corre :)
A menudo he descubierto que el mejor enfoque al llamar la atención de la gerencia sobre estos asuntos no es quejarse de las complejidades del código o de lo difícil que es desarrollarlo, sino brindar una descripción clara de un problema causado por esa estructura
En su caso, con una gran cantidad de excepciones tragadas, proponga un problema fácilmente explicable y reproducible, por ejemplo:
Y esto probablemente captará su atención mucho más rápido. Es una cuestión de enmarcar:
"Tengo un problema con el código base que hace que sea muy difícil escribir y mantener este código sin introducir errores. ¿Puedo cambiarlo, por favor?"
este es tu problema
"Tengo un problema con el código base. He encontrado [Insertar un problema de negocios horrible aquí] que parece surgir en gran medida de la estructura utilizada para escribir esto. ¿Puedo tener tiempo para cambiarlo, por favor?"
Esto es lo mismo, pero ahora es un problema para su jefe y, por lo tanto, es más fácil reservar tiempo para que usted pueda trabajar en ello.
El código que es tan difícil de escribir y mantener como usted describe también es mucho más probable que tenga problemas tan terribles. Cualquier cosa que atrape y coma excepciones regularmente conducirá a la posibilidad de que sucedan todo tipo de rarezas.
Lilienthal
Pedro Mortensen