Estoy horrorizado por el código que escribí hace 3-4 años. El código es tan malo que quiero pegarme un tiro en el pie leyéndolo, y tengo que mantenerlo ahora. ¿Esto es normal?

Creo que es normal, especialmente al principio de la carrera. Cuando recién comienza, o incluso después de cinco o diez años, unos pocos años pueden marcar una gran diferencia en cómo piensa sobre el código.

En mi caso, después de 38 años de hacer esto profesionalmente, más otros cuatro o cinco años de autoaprendizaje antes de eso, lo que tiende a ser diferente sobre mi código más nuevo es que es más probable que esté en un idioma diferente, incorpore nuevas funcionalidades agregado a idiomas existentes, o use nuevas bibliotecas / API. Es menos probable que sea fundamentalmente diferente después de tres o cuatro años.

Lo que no quiere decir que no pueda suceder: existen algunas diferencias bastante grandes entre mi código escrito en 2005 y el escrito en 2008. Durante ese tiempo, formé parte de un equipo que aprendió Scrum y descubrió lentamente cómo hacerlo. pruebas unitarias, que tuvieron un efecto bastante grande en cómo todos nosotros diseñamos el código. Incluso durante ese período, hubo momentos en que estaba trabajando con código escrito anteriormente en el proyecto y me horroricé. Aprendimos mucho durante esos años.

Mirar hacia atrás en los proyectos de codificación anteriores con remordimiento o incluso arrepentimiento es perfectamente natural, normal y sensato . Si codifica lo suficiente, su metodología personal (administración de archivos, creación de sus propias clases y bibliotecas, adopción de sus propias “mejores prácticas”, incluso la forma en que comenta su código) puede evolucionar con el tiempo, tal vez incluso hasta un punto en el que pueda tener inventó una especie de marco de trabajo.

Alguien puede preguntar “¿Por qué no simplemente hacerlo bien la primera vez?” Por lo que sabes, tal vez creías que eras; tal vez a veces lo hiciste. Sin embargo, las cosas cambian más allá de su control: versiones de idiomas, servidores, marcos, mejores prácticas, etc. Quizás los teléfonos inteligentes y las tabletas, y por lo tanto el concepto de diseño web receptivo , no existían cuando creó sus primeras aplicaciones. Puede ser todo lo que puede hacer para mantenerse al tanto de los cambios o ser reemplazado por alguien que ya lo es.

Si tiene la oportunidad, y el permiso , de volver a visitar un proyecto antiguo y revisar todo lo que ha hecho, aproveche el momento mientras pueda, ya sea para mantenerse en forma entre proyectos o para dejar un “marco” comprensible para quien quiera hereda tus proyectos, incluso si fueras el único codificador de esos proyectos.

No todos los programadores pueden regresar y rehacer las cosas. Algunos codificadores pueden encontrarse en una situación en la que pueden encontrar mejores formas de abordar los proyectos, solo para que un supervisor les diga: “Si no está roto, no lo arregles”. (En ese momento, considere buscar empleo en otro lugar o tal vez hacer negocios por sí mismo).

Hagas lo que hagas, no te dispares en ningún lado . Es código y solo código. 😉

Ah, la maldición de la experiencia.

No soy un chico de ciencias de la computación, pero lo que usted describe no es exclusivo de ese campo. Cuando estaba en la universidad, una vez redescubrí algunos ensayos antiguos que había escrito en la escuela secundaria, y estaba igualmente horrorizado por su calidad en comparación con los nuevos estándares a los que me había acostumbrado.

Esto es normal. De hecho, debe considerar esto como un signo de logro. Significa que has mejorado de lo que eras antes.

Cada programador tendrá un código que mirarán y pensarán “¿Qué estaba pensando?” Y, a veces, cuando se trata de un error oscuro, “¿cómo funcionó este código?”.

Se trata de aprender y desarrollar su oficio, y sucede en casi todo lo que hace la gente, desde la música hasta el arte y la programación. También es por qué la experiencia importa incluso en la programación.

En general, no, pero llevo ganándome la vida con la programación durante más de 3 décadas, por lo que estoy seguro de que ya debería haber sido bueno. Pero aún así, de vez en cuando, me encuentro con algo que fue escrito bajo una tremenda presión de programación, donde el dominio del problema real no se entendió bien, o incluso se entendió mal, y lo solucioné durante 3-4 meses después. el código y pensar “Wow, ¿estaba vagando por el bosque cuando escribí esto?” De hecho, esto sucedió esta semana, algo que tuve que crear un parche para un cliente muy importante.

Como muchos otros dijeron, cuando estás aprendiendo, debes mejorar continuamente, incluso en el transcurso de unos pocos meses. Lo mismo para escribir en un nuevo idioma en cualquier momento de su carrera. Puedo escribir programas razonablemente buenos en casi cualquier idioma, pero conocer los matices de un idioma y las enormes bibliotecas de soporte que vienen con la mayoría de los nuevos lenguajes de programación requiere tiempo y experiencia. Considera esta una experiencia muy positiva. E invite a sus compañeros de trabajo a un buen código de burla.

Depende de por qué estás horrorizado. Si está horrorizado porque es innecesariamente complicado y usa toda la nueva sintaxis moderna que ahora está abandonada, es triste pero normal. Si está horrorizado porque está escrito en lo que parece BASIC y hay una línea de comentarios para cada línea de código, no debería estar horrorizado en absoluto. Significa que tuvo el buen sentido de escribirlo para que cualquier imbécil pudiera entenderlo unos años más tarde y portarlo fácilmente al último lenguaje de moda. Esto es lo que siempre he hecho, y cuando miro el código antiguo y realmente puedo entender lo que hizo (ver “imbécil” …) Estoy muy orgulloso de mi sabiduría.

Si definitivamente.
Me las arreglé para no gustarme el código que escribí hace un mes (después de leer Diseño práctico orientado a objetos en Ruby).

La razón es simple, estás mejorando , lo que siempre es algo bueno.
Sí, sentirá lástima por las personas a las que entregó el código, pero no puede hacer nada al respecto.

Sigue mejorando y desea que siempre te desagrade tu antiguo código.

Es normal.

Esa es la razón por la que normalmente miro el código que escribo ahora, no como la próxima gran cosa, sino como una forma tecnológica de alcanzar los objetivos que tengo ahora.

En mi humilde opinión, tendemos a considerar nuestro código como algo que admite todas las cosas conocidas sobre el buen desarrollo de software. Tendemos a comportarnos ya que nuestro código será reutilizado por cientos de desarrolladores. Tendemos a comportarnos ya que nos identificaremos por el resto de nuestras vidas.

El mantenimiento, a pesar de lo que dicen los académicos, siempre es un papel triste, incluso con el código más perfecto jamás escrito. Tienes esta actitud porque ahora sabes lo que no sabías cuando escribiste tu código, pero cuando escribimos nuestro código nunca sabemos cuál será el próximo cambio de requisito. La inyección de dependencia, SOLID, TDD y técnicas similares son buenas, verdaderas, pero siempre he considerado el mantenimiento como el lado oscuro de la programación, a pesar de las mejores prácticas.

En cualquier actividad humana, comprende lo que debería haber hecho antes: este es solo un caso de este principio general.

Si, esto es normal. He revisado algún código antiguo que escribí y me di cuenta de la estupidez e inexperiencia. Creo que todos lo hacen.

Lástima que tengas que mantenerlo. Bwahahaha

Completamente normal No repitas los mismos errores la próxima vez. Repetir. Después de 15-20 años deberías progresar más allá de hacerlo.

Luego puede pensar en otras cosas que podría haber hecho mejor, como asesorar a ingenieros junior, administrar personas, comprender las perspectivas comerciales al unirse a empresas, etc.

Yo diría que es normal, pero con una advertencia. Como han señalado innumerables otros, esta reacción generalmente proviene de haber aprendido más sobre cómo escribir un buen código. Cuando ese es el caso, el “factor de crisis” debería aumentar monotónicamente con la edad. Sin embargo, si observa que se encoge más al mirar el código escrito hace dos años que al código escrito hace cinco años, eso podría indicar algo diferente. Podría significar que estuvo bajo una presión extraordinaria hace dos años y tomó atajos que sabía que no debería tener. Podría significar que estabas desmotivado y que no te importaba. Podría significar que te encontraste con una mala multitud, es decir, las API / estándares / modismos locales hicieron que sea difícil o incluso imposible seguir las mejores prácticas aprendidas desde entonces. En esos casos, vale la pena considerar por qué su calidad se hundió y si ha aprendido las habilidades (no técnicas) para evitar que vuelva a suceder.

¡No solo es normal, debe DESEARSE! La codificación es un oficio. Y como todo buen artesano, siempre deberíamos estar mejorando en nuestro oficio.

Si miras hacia atrás a tu propio código hace 3 o 4 años y no puedes pensar en ALGO que podrías haber hecho mejor, entonces es probable que no te hayas desafiado de una manera que te hubiera hecho crecer en esos años intermedios.

Pero si has estado creciendo, entonces sabes más. Ya sea más sobre el espacio problemático o la tecnología subyacente o los patrones de diseño o … Eso no quiere decir que todo su código pasado será inútil. Probablemente habrá algunas gemas allí. ¡Pero la sensación de “si supiera lo que sé ahora” es completamente normal y saludable!

* Tenga en cuenta que hay circunstancias en las que el código que escribió es demostrablemente óptimo (como una solución algorítmica o algo basado en el hardware / entorno del sistema). En esos casos, es genial sentir orgullo … y luego robar generosamente de tu antiguo yo self

He estado luchando personalmente el mismo problema por un tiempo. Uso código abierto y software, pero me sentía culpable de no haber contribuido nada. Así que decidí poner algo de mi código (pequeños bits) que escribí hace un par de meses en Github. El único obstáculo es el hecho de que me da vergüenza reconocer públicamente que en realidad escribí ese desastre deplorable.
Por lo que entiendo, estamos aprendiendo constantemente y pulimos nuestras habilidades. Entonces, aprendemos nuevas formas de hacer las cosas mejor.
Una pequeña cosa que ayuda un poco al mirar el código antiguo, es comentarlo para explicar claramente qué lógica está utilizando y qué está tratando de lograr.
“El código te dice cómo, los comentarios te dicen por qué”

Si perfectamente normal. En algún momento, el mejor proyecto es el que puedes escribir por segunda vez. Siempre lo mejoras. Esto no significa que el intento anterior fue inferior, se basó en una base de conocimiento diferente, la que estaba vigente en ese momento. La nueva versión incorpora todas las lecciones aprendidas mientras “construye” la primera versión.

Es normal y cuanto más terrible es, más has crecido como desarrollador. Sé feliz por eso. 🙂

Además, en caso de que la versión anterior del código se esté utilizando en algún lugar crucial y piense que la aplicación puede beneficiarse de la mejora del rendimiento, asegúrese de mencionarlo al usuario / administrador final. Hágales saber eso; ” Tengo una mejor manera de hacer la misma tarea. Si me dejas hacerlo, la aplicación será la misma pero menos propensa a fallar con una mejora significativa del rendimiento.

En mi caso, tales adiciones de valor siempre fueron apreciadas por los clientes y se pagan a largo plazo cuando es posible que deba volver para obtener nuevas mejoras. 🙂

Cuando miro sitios web (o códigos) que creé en los años 90, lo veo de la misma manera que hago fotos mías, artículos escritos, poesía escrita o cualquier otra forma de expresión creativa. Puedo ser una persona diferente ahora, y puedo hacer un trabajo diferente en un nivel diferente ahora; pero no estoy “horrorizado” por la persona que era. Entonces, en su caso, si se siente “horrorizado” por el código que escribió hace unos años, diría que probablemente está siendo bastante brutal consigo mismo, pero si eso es lo que quiere hacer, entonces está bien, pero También hará que la codificación sea menos agradable a largo plazo (que es algo de lo que se trata, ¿no?)

Si usted es cualquier tipo de programador / programador o desarrollador profesional, cualquier tipo de desarrollador web profesional o cualquier otro tipo de profesional de servicios para el caso, desea mejorar su oficio con el tiempo. Son las personas que venden basura reciclada por el “cambio rápido” y no les importan las personas de las que se aprovechan, o las personas que no se enorgullecen de nada de lo que hacen, que deberían estar “horrorizados” y no alguien trabajando Honestamente y con integridad.

No hay “normal”. Vivir en la sociedad moderna te mostrará ese punto muy rápidamente. Pero hay formas de conducta a las que la mayoría se suscribe. Golpearse a sí mismo es aceptado en muchos segmentos de la sociedad, que intentan capacitar a las personas para “desempeñarse” temporalmente para profesiones o trabajos de alto estrés. Las personas finalmente se agotan con este tratamiento o se descomponen de una forma u otra o dejan lo que están haciendo porque ya no es agradable. Por lo tanto, si es “normal” golpearse o no es irrelevante, pero no es divertido ni agradable, y abarata la codificación / programación y todo lo relacionado con ello al hacer que sea una competencia y menos un oficio.

De hecho, así es como calculo mi mejora en el dominio de la codificación: cada vez que miro mi código escrito hace un año, una buena parte de él debería disgustarlo. De lo contrario, o no estoy trabajando lo suficiente en mi oficio o he entrado en una fase de retorno disminuido de ese lenguaje de programación particular (o un subconjunto particular de características de ese lenguaje) y debería pensar en aprender algo nuevo.

Sí, particularmente si es uno de los primeros códigos que escribiste. No te preocupes. En cualquier momento X, tu código es increíble. En cualquier año X + 1, es terrible. Parte de convertirse en un mejor programador es aprender a dispararle en el futuro con menos frecuencia 🙂

Si, es muy normal. Sin embargo, ocurre principalmente cuando falta documentación y comentarios para acompañar. Mantener buenos documentos y comentar bien su código es la clave para evitar que esas cosas sucedan una y otra vez …

Mantener la práctica de comentar el código no solo es bueno para el codificador original (autor) sino también para el auditor y la persona que puede hacerse cargo del proyecto en caso de adquisición.

Especialmente mientras estaba aprendiendo, tuve más de una ocasión en la que exclamaba “¿Qué idiota escribió este pedazo de … erm, oh, supongo que ese era yo”.

Aprendes a través de la experiencia. Si su código de hoy es mucho mejor que el código que escribió hace 3 o 4 años, lo está haciendo bien.