código sentimental [cerrado]

Question

Me he encontrado con un artículo que trata el tema de la "admiración del código". Básicamente, el autor habla sobre cómo los desarrolladores deberían ser más escépticos sobre el código que escriben. Cómo podemos "admirar" nuestro código demasiado, adjúntese a él, haciéndonos más vulnerables a los errores y otros percances que puedan estar frente a nosotros.

¿Cómo te sientes acerca de este problema? ¿Y tiene más consejos sobre cómo evitar / ser más consciente de este problema?

Answer 1

Hace algunos años, estaba trabajando con otro en un pequeño "hobby" proyecto, y me di cuenta de que teníamos que volver a evaluar las cosas. Habíamos escrito mucho código pero no todo era un buen código.

Realmente no queríamos "tirar" todo el trabajo que habíamos puesto. Pero me di cuenta de algo: lo que más importaba era la cantidad de trabajo que necesitaríamos poner en de ahora en adelante .

No pudimos cambiar el hecho de que ya habíamos puesto tanto trabajo en el proyecto, por lo que la única forma de minimizar la cantidad total de trabajo que necesitaría el proyecto sería minimizar el cantidad de trabajo que aún no habíamos hecho .

Desde ese día, he dejado de estar conectado a mi código. Si estoy seguro de que tirarlo y comenzar desde cero significa menos trabajo que mantenerlo y adaptarlo a mis necesidades, lo tiraré.

Answer 2

Mi maestra de arte de la escuela secundaria solía animarnos a tomar lo que consideramos nuestros mejores dibujos y romperlos; a esto lo llamó "limpiar el alma". Su razonamiento fue que, como artistas, estábamos impulsados ??a crear obras de arte, y cada vez que producíamos algo que nos gustaba y que nos daba satisfacción, nuestra motivación para continuar creando se vería disminuida.

Así que seguí su consejo y rompí mis mejores cosas, y funcionó. En lugar de pasar mi tiempo admirando mi antiguo trabajo, creé cosas nuevas y mejoré continuamente. Intenté seguir el mismo principio con mi código, pero en realidad no funciona: mi computadora tiene una carcasa de plástico resistente que es casi imposible de romper.

Answer 3

Publico un fragmento del blog de Jeff Atwood, Chupando menos cada año , y estoy de acuerdo al 100%.

  

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

Answer 4

Seguro que nos gusta admirar nuestro buen código, pero no siempre es fácil saber qué admirar. El código complicado y elaborado a veces se confunde con un código admirable, mientras que la elegancia y la simplicidad deberían ser lo que se debe buscar.

Me vienen a la mente dos citas:

  

" La depuración es el doble de difícil que escribir   El código en primer lugar.   Por lo tanto, si escribe el código como   lo más inteligente posible, eres, por   definición, no lo suficientemente inteligente como para depurar   ".

     

- Brian Kernighan

y

  

" Haga que todo sea tan simple como   posible, pero no más simple. "

     

- Albert Einstein

Answer 5

Jonathan Edwards escribió un ensayo impresionantemente hermoso sobre este tema, impulsado por el trabajo sobre el libro de O'Reilly Beautiful Code . Aquí está el párrafo final, pero también vale la pena leer el resto del ensayo.

  

Otra lección que aprendí es desconfiar de la belleza . Parece que el enamoramiento con un diseño inevitablemente conduce a la angustia, a medida que se introducen realidades feas pasadas por alto. El amor es ciego, pero las computadoras no lo son. Una relación a largo plazo, mantener un sistema durante años, le enseña a uno a apreciar más virtudes domésticas, como la sencillez y la convencionalidad. La belleza es una fantasía idealista: lo que realmente importa es la calidad de la conversación interminable entre el programador y el código, ya que cada uno aprende y se adapta al otro. La belleza no es una base suficiente para un matrimonio feliz.

Existen otras versiones de esta misma sabiduría en otros campos. Samuel Johnson, sobre escribir:

  

Lee tus composiciones, y donde sea que te encuentres con un pasaje que creas que está particularmente bien, tachalo.

La versión de William Faulkner de esto fue mucho más sucinta: "Mata a tus seres queridos".

Mi suegro trabaja como editor de cine, y evita cuidadosamente el set donde se filma la película. Cuando tiene que visitar, se protege los ojos tanto como puede. Esto se debe a que cuando decide si incluir o no una escena en la película final, no quiere verse influenciado por el esfuerzo que le tomó filmar la escena. Lo que importa es qué tan bien funciona la escena en la película final.

Mi ensayo, "Mi evolución como programador" (que vincularía si no fuera un usuario nuevo), se trata principalmente de aprender escepticismo sobre el código que escribí: si funciona, si es útil, si es comprensible (la programación de pares fue una verdadera llamada de atención aquí). ¡Es difícil!

Answer 6

Nunca admiro mi código. Admiro el código de otras personas que "tomo prestado" e intento emularlos o mejorarlos y descubro que cuanto más sé, especialmente sobre la codificación, más encuentro que no sé. Lo único valioso sería que los programadores pares admiren mi código y lo pidan prestado.

Answer 7

Creo que tiene un buen punto. Es frustrante trabajar con personas que tienen demasiado de esto, ya que realmente dificulta el trabajo en equipo y llegar a la mejor solución al problema.

Como puedo ser un poco delirante, trato de poner en práctica prácticas que me mantengan conectado a la realidad. Para el código,

• pruebas unitarias : me mantienen más centrado en lo que se supone que debe hacer el código, en lugar de cualquier resumen de belleza.

• propiedad de código compartido : hay dos campos aquí: otorgar a las personas más propiedad de su código y esperar que el orgullo se apodere, o darles menos y dejar que la presión de grupo entre en juego. Creo que darles más propiedad a las personas puede generar admiración por este código. Practicamos la propiedad del código compartido, por lo que me veo constantemente obligado a ver a alguien reescribir mi código perfecto para mejorarlo (en su opinión). Rápidamente me di cuenta de que admirarlo demasiado era una pérdida de tiempo y emocionalmente difícil.

• programación de pares : trabajar codo a codo con alguien te mantendrá realista.

• otros comentarios : Todos estos son bucles de comentarios, pero hay otros. No hay mejor manera de ver si algo funciona que viendo a alguien (intentar) usarlo. Pon tu trabajo frente a tantas personas como sea posible. Tener revisiones de código. Lea el código de otras personas . Ejecute herramientas de análisis de código estático .

Answer 8

Estoy con PurplePilot: no admiro mi propio código y, como tal, busco constantemente nuevas formas más eficientes (demonios, más fáciles) de hacer lo mismo. Me gusta el libro Effective c #, recogí muchos códigos útiles de allí que admiro.

No dudaría en tirar el código y comenzar de nuevo, pero no necesariamente desde cero, es decir, al escribir un código para un escenario específico y luego tirarlo, probablemente tendrá una mejor comprensión del escenario. En otras palabras, es un '' problema perverso '', o has encontrado otra forma que no funciona a la Edison.

Plantea una pregunta más amplia: si el código no se descarta, o al menos se revisa, ¿se está desarrollando en bibliotecas que se estancan algo bueno?

Answer 9

No hay nada de malo en admirar su código ... esto es parte del proceso de refuerzo positivo que lo motivará a escribir más y mejor código en el futuro.

Sin embargo, la admiración fuera de lugar o mal uso puede ser un problema. Si el código no es realmente bueno, o tiene errores que no han sido expuestos por la unidad u otras pruebas, o necesita refactorización / rediseño / reemplazo, entonces esta admiratoína fuera de lugar es un problema. Y usar la admiración como una excusa para saltear parte del proceso, como las revisiones de código, o no tener una actitud escéptica hacia el código, es mal uso de la admiración.

Al igual que cualquier otra cosa que sea buena, la admiración del código puede ser extraviada o mal utilizada, no significa que en sí misma sea mala. Eso sería como decir "la religión es algo malo, porque causa conflictos y guerras entre las personas".

Answer 10

Dos palabras: revisión de código.

Reúna a dos o más desarrolladores desarrolladores e invítelos a revisar / criticar / comentar su código. 'arrojará algo de luz (ciertamente dura) sobre su código.

Answer 11

Tal vez sea mejor tener una perspectiva más saludable: no somos científicos de cohetes y no estamos curando el cáncer, es solo trabajo.

(Sí, es razonable estar orgulloso de un edificio completo que ayudaste a construir si eres arquitecto, pero ¿realmente tienen mucha de su autoestima envuelta en un plano individual o en un armario en el piso 3? diseñaron por sí mismos?).