Chupando menos cada año? [cerrado]

Chupando menos cada año -Jeff Atwood

Me encontré con este artículo perspicaz. Cita directamente desde la publicación

A menudo he pensado que chupar menos cada año es cómo mejoran los humildes programadores. Deberías estar descontento con el código que escribiste hace un año. Si no lo está, eso significa que A) no ha aprendido nada en un año, B) su código no se puede mejorar o C) nunca vuelve a visitar el código antiguo. Todos estos son el beso de la muerte para los desarrolladores de software.

1. ¿Con qué frecuencia te sucede esto o no?
2. ¿Cuánto tiempo antes de que vea una mejora real en su codificación? ¿mes año?
3. ¿Alguna vez vuelves a visitar tu antiguo código?
4. ¿Con qué frecuencia te atormenta tu antiguo código? o con qué frecuencia tiene que lidiar con su deuda técnica.

Definitivamente es muy doloroso corregir viejos errores y códigos sucios que podríamos haber hecho para cumplir rápidamente con una fecha límite y esas soluciones rápidas, en algunos casos es posible que tengamos que reescribir la mayor parte de la aplicación / código. No hay argumentos sobre eso.

Algunos de los desarrolladores con los que me he encontrado argumentaron que ya estaban en la etapa evolucionada donde su codificación no necesita mejorarse o ya no puede mejorarse.

• ¿Esto pasa?
• Si es así, ¿cuántos años de codificación en un idioma en particular se espera que esto suceda?

Relacionado:

¿Alguna vez has visto algunos de tus viejos códigos y has hecho una mueca de dolor?

Star Wars Moment in Code "¡Luke! ¡Soy tu código!" "¡No! ¡Imposible! ¡No puede ser!"

  > Sucking Less Every Year ?

No pero chupando diferente cada año :-)

Después de mis primeras críticas hace muchos años, sufrí por la falta de convenciones de nomenclatura.

Luego sufrí que mi código fue implementado (innecesario) para ser lo más genérico posible, pero eso hizo que el código fuera difícil de entender y mantener.

Luego, aprendí el desarrollo impulsado por pruebas, InversionOfControl, qué genéricos de red de puntos dónde y muchos más.

conclusión

El sufrimiento de los viejos hábitos malos disminuyó pero fue compensado en exceso por los nuevos sufrimientos que tuve porque aprendí más.

Curiosamente, todos los programadores "rockstar" con los que trabajé fueron extremadamente humildes, ansiosos por aprender y dispuestos a admitir que no lo saben todo. Demonios, muchos eran en realidad autocríticos, al menos en momentos alegres.

No creo haber conocido a un desarrollador que piense que su codificación "no se puede mejorar", pero algo me dice que estos chicos estarían tan lejos de Rockstar como puedas, por decirlo suavemente.

Los siguientes puntos no son consejos sino un registro personal:

• usando menos variables globales
• no use la abreviatura para variables o nombres de funciones
• escribir [algunos] códigos de prueba
• no juzgue el código como lento (o rápido) sin evaluación comparativa
• aprender a cargar, probar una aplicación
• no lo arregles, si no está roto
• use una herramienta de administración de código fuente (git / hg)
• la refactorización es genial, no subestimes el costo de las pruebas que trae
• la seguridad es difícil, así que tenga cuidado con esto lo antes posible
• parchear algunos errores de proyecto de código abierto
• blog algo nuevo
• la usabilidad puede no ser una solicitud de función, pero es importante

No aprendí todo en un año, todo lleva tiempo ...

A menudo, la gente piensa que el buen código sucede de repente, pero para la mayoría de nosotros, simples mortales, el buen código crece en nuestra base de código. Quiero decir, es muy difícil escribir la pieza de software perfecta desde el principio, ya que los requisitos cambian constantemente y no somos programadores perfectos ni tampoco se toman decisiones estúpidas constantemente por parte de los gerentes y programadores. Luego veo que cada requisito cambia una buena oportunidad para refactorizar parte del código antiguo en un código mejor (¡y que se me pague por ello!) Y pagar un poco de deuda técnica. Como dicen: "deje el repositorio de código un poco mejor cada vez que confirme código". Entonces su sistema evolucionará hacia un sistema más cercano al ideal.

No conozco absolutamente ningún programador que esté orgulloso de su software, pero eso es bueno. Que significa que el programador ha aprendido en el proceso.

Además, si lee el libro "Código limpio", aumentará su propio "factor de succión" varias veces. :RE

De hecho, tengo ambas caras de la moneda para esto.

Por un lado, observa el código antiguo y ve que está lleno de errores y formas complicadas de hacer cosas que simplemente se logran aprovechando las técnicas y las características del lenguaje que no conocía en ese momento.

Por otro lado, ves una solución particularmente elegante a un problema y no puedes evitar lanzar una sonrisa presumida por lo inteligente que eras en ese momento.

Y luego te desplazas un par de líneas hacia abajo y haces una mueca de horror ante el hecho de que usaste GOTO en C.

Hmm ... Con frecuencia estoy bastante gratamente sorprendido por lo bueno que es mi código anterior.

Si lo estuviera haciendo hoy, a menudo lo escribiría de manera diferente, pero si tuviera que vivir con las limitaciones del tiempo, no estoy seguro de que lo haría. Cuando puede contar con una máquina típica que tiene al menos un par de gigas de RAM, puede (y a menudo debería) escribir su código de manera un poco diferente que cuando un disco duro grande tenía 100 megabytes.

1. ¿Con qué frecuencia te sucede esto o no?

2. ¿Cuánto tiempo antes de que vea una mejora real en su codificación? ¿mes año?

3. ¿Alguna vez vuelves a visitar tu antiguo código?

4. ¿Con qué frecuencia te atormenta tu antiguo código? o con qué frecuencia tiene que lidiar con su deuda técnica.

1. Cada vez que aprendo algo nuevo, espero que sea todos los días.

2. Si llego a implementar lo que aprendí, entonces es inmediato desde que lo implemento.

3. Sí, solo para (1) Nuevas características, (2) Corrección de errores, (3) Nostalgia, (4) Vea cómo resolví algo, puede ser útil.

4. En relación con 1., cuando aprendo cómo hacer algo mejor, soy consciente de que algunos proyectos anteriores "podrían" haberse hecho mejor. Los dejo ser. Solo asegúrese de que el próximo proyecto se realice de la mejor manera. No me preocupo a menos que sea un error real.

En otra pregunta , el tema trataba sobre las formas de evaluar la calidad de su propio código. Una de mis sugerencias fue revisarlo en pocos años, cuando su experiencia es mucho mayor que cuando se escribió el código. Una cita de mi respuesta a esta otra pregunta está directamente relacionada con su pregunta:

"en mi caso, la vida útil es de un año: significa que puedo modificar el código que escribí hace seis meses, pero si el código fue escrito hace dos años, tiene una gran posibilidad de ser arrojado, y reescrito completamente, ya que simplemente apesta demasiado ".

Entonces, sí, en la práctica, cada pieza de código que he escrito se vuelve insoportable desde mi punto de vista en un año. Y no estoy hablando del código desechable, sino también del código que he escrito teniendo en cuenta la calidad, la facilidad de mantenimiento y la legibilidad. Por el momento, no hubo excepciones.

Para responder a su segunda pregunta sobre la esperanza de vida, varía mucho. Un código desechable tiene una vida útil de cero segundos : apesta justo después de que lo haya escrito, pero no importa. Algunas piezas de código que he escrito eran soportables después de dos años , pero necesitaban algunos cambios cosméticos: un poco de refactorización, aplicación de las reglas de StyleCop, etc. En promedio, en mi caso preciso, la vida útil varía entre ocho meses y un año para C #, y entre dos y seis meses para PHP.

¿Revisito mi antiguo código? Sí, por supuesto, como todos los desarrolladores, a menos que no te importe DRY y reinvente tu propia rueda una y otra vez. También hay posibilidades de revisar y mejorar el código con mucha frecuencia si tiene una base de código común que utiliza en muchos proyectos . Otro punto es que si trabaja en grandes proyectos, algunos pueden llevarle años , por lo que tendrá que volver a visitar el código anterior.

Algunos de los desarrolladores con los que me he encontrado argumentaron que ya estaban en la etapa evolucionada donde su codificación no necesita mejorarse o ya no puede mejorarse.

Cuando una persona dice que es tan perfecta que no necesita aprender nada, significa que ni siquiera es capaz de comprender lo tonta que es.

Incluso si tiene veinte años de experiencia en computadoras / programación, las cosas cambian demasiado rápido, por lo que siempre hay cosas nuevas que aprender y nuevas técnicas para mejorar el código. Por ejemplo, un código C # escrito cuando no había .NET Framework 3.0 muy probablemente puede hacerse más legible y mejor con las cosas nuevas que tenemos hoy (incluidos Linq, contratos de código, etc.), y esto, incluso si el código anterior fue escrito por el desarrollador más inteligente.

Sucede con bastante frecuencia cuando miro el código y me pregunto: "¿Qué estaba pensando cuando escribí esto?"

Por lo general, hay mejoras todo el tiempo, ya que a veces se me ocurre una nueva idea para organizar el código, diseñar el código u otra cosa y, aunque puede que no sea una gran mejora, cada pequeña cosa puede ayudar.

Dependiendo del entorno de trabajo, es posible que vea código de hace unos años, ya que continúo trabajando en la misma base de código y estoy bastante familiarizado con lo que hay y es algo que debo administrar.

El código antiguo casi siempre me atormenta, ya que generalmente estoy cambiando un sistema existente o reemplazando el sistema. En cualquier caso, tengo que conocer las peculiaridades del sistema existente para asegurarme de que estén allí en el nuevo.

Si bien estoy seguro de que hay personas como Jon Skeet que pueden pensar en un código perfecto, la mayoría de las personas que dicen que su código no se puede mejorar lo dicen desde un punto de ego que podría no ser atractivo. Al mismo tiempo, en términos de encontrar una gran mejora cada vez que no siempre será el caso.

1. ¿Con qué frecuencia te sucede o no?

¿Con qué frecuencia no estoy satisfecho con mi antiguo código? Casi siempre. Hay raras excepciones en las que tengo código del que estoy realmente orgulloso ... pero, de nuevo, son raras. Me dijeron que el código que escribí hace un par de años era bueno ... Me estremecí y pensé "pobre persona pobre por haber visto algo peor que la basura que escribí".

2. ¿Cuánto tiempo antes de ver una mejora real en su codificación? ¿mes año?

Por lo general, está en etapas ... Me meto realmente en un estilo o metodología (tome interfaces fluidas, por ejemplo ... ya que ese fue el último estilo para el que tuve un gran mojado) y carnicé todo lo que escribí durante un mes o cuatro . Entonces comienza a verse mejor.

3. ¿Alguna vez volvió a visitar su antiguo código?

No tan a menudo como me gustaría. La mayor parte de mi antiguo código es propiedad de empleadores anteriores. El código personal se blanquea con demasiada frecuencia.

4. ¿Con qué frecuencia te atormenta tu antiguo código? o con qué frecuencia tiene que lidiar con su deuda técnica.

Siendo que los empleadores anteriores tienen la mayor parte de mi código anterior, y blanqueo la mayor parte de mi código personal ... no muy a menudo.