Chupando menos cada año? [cerrado]

10

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!"

Aditya P
fuente
3
En mi humilde opinión, las personas que piensan que son perfectas y que no necesitan mejorar tienen razón. No pueden mejorar. Cualquier persona sensata sabe que nunca puede ser perfecta, siempre hay espacio para mejorar / aprender cosas nuevas. Me horrorizaría si descubriera que no puedo mejorar, no quiero pensar que tengo un techo.
MAK
Me encanta volver a los proyectos que hice cuando era muy nuevo, y mirar el código que me resultaba tan difícil de escribir. Muchas veces el código es muuuy simple. Me hace reír.
The Muffin Man el

Respuestas:

6
  > 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.

k3b
fuente
19

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.

Mesas Bobby
fuente
2
Estoy de acuerdo al 100% ¡Son asesinos silenciosos! Ah, y nombre de usuario increíble, xkcd :)
jamiebarrow
@jamiebarrow: Por supuesto. :)
Bobby Tables
otro caso de falla es la persona que dice "todo el software es malo, todo es pirateo, sus ideas para mejoras no importan". Es un poco deprimente trabajar con esos tipos.
Doug T.
13

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 ...

Oh ho
fuente
Me gusta cómo mencionas "escribir [algunos] códigos de prueba". Creo que nadie alcanza la perfección donde nunca cometerá un error como programador: todos somos humanos y cometemos errores de vez en cuando. Las pruebas unitarias y las pruebas de integración pueden reducir nuestros errores. Y me doy cuenta de que dices 'algunas' pruebas, lo cual es importante, porque a veces me he dejado llevar escribiendo pruebas que no fueron realmente útiles.
jamiebarrow
De hecho, creo que debajo de "no lo arregles, si no está roto", agregaría "Si está roto y es complicado, reproduce y corrige el error con el código de prueba"
jamiebarrow
2
¿Puedo agregar algunos? Si se trata de una API, no exponga más detalles internos de los necesarios, si lo oculta, puede cambiarlo más tarde. Siempre use constantes en lugar de números mágicos porque son más fáciles de documentar y cambiar. La inmutabilidad es extremadamente útil, especialmente cuando se trata de concurrencia. Trabajar en la base de código de otra persona, es un proceso infinitamente valioso para juzgar su propio estilo de codificación cuando tiene que justificarlo ante otra persona. Obtenga la especificación congelada (si es posible) porque es más difícil alcanzar un objetivo en movimiento.
Evan Plaice
Si trabaja en el sitio o cerca de clientes, empaque sus tarjetas sin autoridad y de mayor potencia. Si le piden que cambie algo fuera de la especificación, extraiga la (no tengo) tarjeta de autoridad seguida de la (referencia a) una tarjeta de mayor potencia (preferiblemente un PM externo que pueda aceptar las solicitudes). El mejor de los casos, lo liberará para concentrarse en el desarrollo; En el peor de los casos, reducirá la cantidad de solicitudes de funciones de conducción. (controvertido) Regrese temprano y regrese a menudo, si el retorno debía ocurrir al final de un bloque de código, no habría una palabra clave para ello. Con suerte, sigo chupando menos cada año.
Evan Plaice
4

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

Rafa de Castro
fuente
1
No estoy de acuerdo con usted en un punto, creo que puede estar orgulloso de algún código. Lo irónico es que puedes hacer que un proyecto salga extremadamente bien y estar orgulloso de él, con quizás algunas pequeñas molestias. Luego, en el próximo proyecto, sus WTF por hora son altos ... ¡para su propio código! : D
jamiebarrow
1
Tal vez depende del paso que estés ahora. Ahora encuentro el código que escribí hace un año e incluso me resulta difícil entender algunos nombres o el propósito de algunos métodos. También encuentro código descubierto por pruebas y cosas así. A medida que sigo mejorando, cosas como esas tienden a ser excepciones más que una norma y empiezo a avergonzarme de problemas que antes parecían no ser importantes ...
Rafa de Castro
+1 para código limpio, aunque es la comparación siempre con usted mismo.
Aditya P
4

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.

Chris Browne
fuente
3

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.

Jerry Coffin
fuente
3
  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.

Noche oscura
fuente
3

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.

Arseni Mourzenko
fuente
Es más como si preguntaras esto, corres el riesgo de parecer como alguien que no sabe cómo escribir un buen código.
Aditya P
@AdityaGameProgrammer: Hay una diferencia para hacer entre código con errores, feo y buen código que, después de un año o menos, puede escribirse de una manera más elegante. (1.) Nadie puede escribir un código perfecto que se mantenga perfecto para siempre, por lo que debemos admitir que nuestro código se puede mejorar con el tiempo. (2.) Adquirimos experiencia y conocimiento a lo largo del tiempo, lo que también es fuente de mejora del antiguo código.
Arseni Mourzenko
1

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.

JB King
fuente
1

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.

Steven Evers
fuente
lavado blanco = re-factor? ¿te refieres a un código de proyecto o tu base de código personal?
Aditya P
1
@AdityaGameProgrammer: lavado blanco = tirar todo y volver a escribirlo desde el principio. Estoy hablando de mi código personal.
Steven Evers