¿Cómo saben los programadores rápidos y sucios que lo hicieron bien?

El código probablemente no sea correcto.

Sin embargo, puede que no importe.

Rápido y sucio puede ser el camino correcto en situaciones donde:

• El código tiene una vida útil corta . Por ejemplo, está transformando un montón de datos en un formato estándar con un programa ad-hoc.
• El impacto negativo de la falla es bajo :
  • Los datos que está transformando no son críticos, y los errores pueden ser corregidos fácilmente
  • El usuario final es un programador simpático, que razonará acerca de los mensajes de error y los evitará, por ejemplo, dando masajes a la entrada.

A veces no es importante que el código sea robusto y maneje cada entrada concebible. A veces solo es necesario manejar los datos conocidos que tiene a mano.

En esa situación, si las pruebas unitarias lo ayudan a escribir el código más rápido (este es mi caso), entonces utilícelos. De lo contrario, codifique rápido y sucio, haga el trabajo. Los errores que no se activan no importan. Los errores que corrige o soluciona sobre la marcha no importa.

Lo que es absolutamente vital es que no diagnostiques mal estas situaciones. Si codifica rápido y sucio porque el código solo se usará una vez, entonces alguien decide reutilizarlo en algún proyecto que merece un código mejor, ese código merecía más atención.

No lo hacen. Actualmente estoy trabajando en una base de código creada por programadores "rápidos y sucios" que "lo limpiarían más tarde". Se han ido hace mucho, y el código sigue vigente, abriéndose camino hacia el olvido. codificadores Cowboy , en general, simplemente no entienden todos los modos de falla potenciales que puede tener su software y no lo hacen No entiendo los riesgos a los que están exponiendo la empresa (y los clientes).

De acuerdo, a riesgo de ser un completo cebo a la baja, voy a "defender a los demonios" desde el punto de vista opuesto.

Propongo que nosotros, los desarrolladores, tengamos una tendencia a preocuparnos demasiado por cosas como la práctica adecuada y la limpieza del código. Sugiero que, si bien esas cosas son importantes, nada de eso importa si nunca envías .

Cualquiera que haya estado en este negocio por un tiempo probablemente estaría de acuerdo en que sería posible jugar con un software más o menos indefinidamente. Duke Nukem para siempre, mis amigos. Llega un momento en el que esa característica agradable de tener o que, oh, un trabajo de refactorización tan urgente, simplemente debería dejarse de lado y la cosa debería llamarse HECHO.

He peleado con mis colegas acerca de esto muchas veces. SIEMPRE hay un truco más, algo más que "debería" hacerse para que sea "correcto". SIEMPRE puedes encontrar eso. En algún momento, en el mundo real, lo suficientemente bueno solo tiene que ser lo suficientemente bueno. Ningún software real, de envío real es perfecto. Ninguna. En el mejor de los casos, es lo suficientemente bueno.

Tales programadores casi nunca saben lo hicieron bien, solo creen así. Y la diferencia puede no ser fácil de percibir.

Recuerdo cómo solía programar antes de aprender acerca de las pruebas unitarias. Y recuerdo ese sentimiento de confianza y confianza en un nivel completamente diferente después de que ejecuté mi primer conjunto decente de pruebas unitarias. No sabía que tal nivel de confianza en mi código existía antes.

Para alguien que carece de esta experiencia, es imposible explicar la diferencia. Por lo tanto, pueden continuar desarrollándose en modo de código y oración a lo largo de su vida, creyendo benevolentemente (e ignorantemente) que están haciendo todo lo posible teniendo en cuenta las circunstancias.

Dicho esto, de hecho puede haber grandes programadores y casos excepcionales, cuando uno realmente logra mantener todo el espacio del problema en su mente, en un estado completo de flujo. He experimentado momentos raros como este, cuando sabía perfectamente qué escribir, el código simplemente se me escapó sin esfuerzo, podía prever todos los casos especiales y condiciones de contorno, y el código resultante simplemente funcionó . No tengo dudas de que hay genios de la programación que pueden permanecer en un estado de flujo tan prolongado o incluso la mayor parte de su tiempo, y lo que producen es un código hermoso, aparentemente sin esfuerzo. Supongo que estas personas pueden sentir que no es necesario escribir pruebas de unidad insignificantes para verificar lo que ya saben . Y si realmente eres un genio, puede estar bien (aunque incluso entonces, no estarás en el proyecto para siempre, y deberías pensar en tus sucesores ...). Pero si no ...

Y seamos sinceros, es probable que no lo estés. Yo, por mí mismo, sé que no soy. Tuve algunos momentos raros de flujo, e innumerables horas de dolor y tristeza, generalmente causadas por mis propios errores. Es mejor ser honesto y realista. De hecho, creo que los mejores programadores son plenamente conscientes de su propia falibilidad y errores pasados, por lo que han desarrollado conscientemente el hábito de verificar dos veces sus suposiciones y escribir esas pequeñas pruebas unitarias, para mantenerse seguros. ( "No soy un gran programador, solo un buen programador con buenos hábitos". - Kent Beck).

Pruebas unitarias . Es la única forma de tener confianza en cualquier código (sucio o no).

En una nota al margen;

  

los atajos hacen que los retrasos largos (Pippin)

Es bueno aprender a aceptar que ningún sistema de software de complejidad razonable será perfecto, independientemente de la cantidad de pruebas unitarias y la modificación del código que se realicen. Cierto grado de caos y vulnerabilidad a lo inesperado siempre acechará dentro del código. Esto no significa que uno no deba intentar producir un buen código o realizar pruebas unitarias. Estos son, por supuesto, importantes. Hay que buscar un equilibrio y esto variará de un proyecto a otro.

La habilidad a desarrollar es una comprensión de qué nivel de "perfección" se necesita usar para un proyecto en particular. Por ejemplo, si está escribiendo una aplicación de registros médicos electrónicos con una línea de tiempo del proyecto de 12 meses, querrá dedicar mucho más tiempo a las pruebas y asegurarse de que su código sea mantenible de lo que lo haría para una aplicación web de registro de conferencia única. Eso tiene que ser desplegado para el viernes. Los problemas llegan cuando alguien que hace la aplicación EMR se descuida o la aplicación de registro no se implementa a tiempo porque el programador está demasiado ocupado para modificar el código.

Rápido y sucio está perfectamente bien dentro de un subsistema . Si tienes una interfaz bien definida entre tu mierda y el resto del sistema, y un buen conjunto de pruebas unitarias que verifican que el código feo y sucio hace lo correcto, puede estar perfectamente bien.

Por ejemplo, tal vez tenga un truco horrible de expresiones regulares y compensaciones de bytes para analizar algunos archivos provenientes de un tercero. Y suponga que tiene una prueba que dice que el resultado que obtiene al analizar los archivos de ejemplo es el que esperaba. Puede limpiar esto para que pueda ... No sé, ¿reaccionar más rápidamente cuando un tercero cambia un formato de archivo? Eso simplemente no sucede lo suficiente. Es más probable que se conviertan en una API completamente nueva y que deseches el analizador anterior y conectes una nueva que se ajuste a la misma API, y listo, ya has terminado.

Cuando lo rápido y lo sucio se convierten en un problema es cuando la arquitectura es rápida y sucia. Su objeto de dominio principal debe estar bien pensado y sus interfaces, pero los bordes de su sistema generalmente pueden estar desordenados sin tener que pagar nunca más.

Aquí hay una historia sobre un programador rápido y sucio que conozco.

He conocido a una persona que considera que las pruebas de unidad son una pérdida de tiempo. Después de mucha discusión, finalmente escribió uno. Consistía en un método largo rociado con & & y || y devolvió un booleano a assertTrue. El enunciado abarca 20 líneas. Por otra parte, escribió una clase donde cada método tenía una línea y el principal tenía más de 1000 líneas sin espacios en blanco. Era una pared de texto. Cuando revisé su código e inserté algunas líneas nuevas, me preguntó "por qué". Dije 'Debido a la legibilidad'. Suspiró y los borró. Puso un comentario en la parte superior "¡No lo toques, funciona!"

La última vez que hablé con él, codificó un sitio web para una empresa. Estaba tratando de encontrar un error. Había pasado los últimos 3 días haciendo eso durante 8 horas al día. Poco después volví a hablar con él, y resultó que su compañero de equipo cambió el valor de un literal y no lo actualizó en ningún otro lugar. No fue una constante. Así que cambió los otros literales también para que su error se arreglara. Se quejó del código de espagueti de su compañero de equipo. Me dijo 'Jaja, no todos sabemos lo que es quedarse despierto toda la noche con el depurador, no dormirnos con un bicho desagradable "Piensa que esto es algo que hacen los programadores muy bien y realmente se siente bien al respecto.

Además, él piensa que leer libros de programación y blogs es inútil. Él dice, 'sólo empieza a programar'. Lo ha hecho durante 12 años y cree que es un excelente programador. / facepalm

Aquí hay algo más.

Otra vez estábamos escribiendo una clase DatabaseManager para nuestra aplicación web. Él puso todas las llamadas de base de datos en él. Era una clase de Dios con más de 50 métodos para cada cosa imaginable. Sugerí que lo dividiéramos en subclases porque no todos los controladores necesitan conocer cada método de base de datos. No estuvo de acuerdo, porque era "fácil" tener solo una clase para toda la base de datos y era "rápido" agregar un nuevo método cada vez que lo necesitábamos. Al final, DatabaseManager tenía más de 100 métodos públicos desde la autenticación del usuario hasta la clasificación de las ubicaciones de los sitios arqueológicos.

Mi lección para evitar lo rápido y lo sucio fue cuando tenía seis meses para entregar lo que se estimaba (se subestimaba) en un año de trabajo. Decidí investigar metodologías antes de empezar a trabajar. Al final, invirtí tres meses de investigación y pude cumplir en los tres meses restantes.

Obtuvimos grandes ganancias al identificar una funcionalidad común y al crear las bibliotecas necesarias para manejar esos requisitos. Todavía veo codificadores que escriben su propio código cuando hay rutinas de biblioteca disponibles. Estos codificadores a menudo reescriben, o en el mejor de los casos cortan y pegan, el mismo código cuando necesitan resolver el mismo problema más adelante. Las correcciones de errores invariablemente solo detectan algunas de las copias de código.

Un desarrollador dio una respuesta contundente cuando le pedí que usara el código de la biblioteca: "¿No es eso un engaño? Tuve que escribir todo mi propio código en la escuela".

En algunos casos, supongo que podría haber un gran conjunto de pruebas de regresión que encontrarán "todos" errores y verificarán el comportamiento, lo que permitirá una técnica de codificación rápida y sucia. Pero principalmente es solo una cuestión de mala planificación de proyectos y un gerente que piensa que es más importante hacerlo, que hacerlo bien.

Y olvídate de "limpiarlo más tarde", eso nunca sucede. En los raros casos en que sucede, el programador habrá olvidado la mayor parte del código, lo que hace que el trabajo sea mucho más costoso que si lo hubiera hecho bien la primera vez.

El producto se envía.

El código no existe en un vacío. He sufrido un dolor incalculable luchando contra las consecuencias de la codificación rápida y sucia y del vaquero. Pero a veces terminar con el producto es la prioridad, no descubrir cómo escribir el mejor código. En última instancia, si el producto se envía y funciona lo suficientemente bien, los usuarios y los clientes no sabrán o les importará cuán "malo" es el código interno, y admitiré que hubo ocasiones en las que no me importó en absoluto "obtenerlo derecho "siempre que lo saque por la puerta.

Sí, esto en un problema de organización y "nunca debería suceder". Pero si está escribiendo un código en una organización que no está bien administrada y está muy motivada por la fecha límite, a nivel de programador individual las opciones son limitadas.

No creo que puedan decir honestamente que lo hicieron bien si no es fácil de mantener. Si admiten que tienen que "limpiarlo más tarde", entonces es probable que haya algo que no hayan pensado lo suficiente. Probarlo a fondo solo descubrirá realmente cualquier problema con el código sucio.

Personalmente, no me gustaría desarrollar la habilidad de "escribir código sucio" y confiar en su corrección. Preferiría escribir el código correcto la primera vez.

¿Cómo saben que lo hicieron bien? La prueba es la respuesta simple.

Si su código ha sido probado exhaustivamente por un buen equipo de control de calidad y pasa, entonces diría que lo hicieron bien.

Escribir un código rápido y sucio no es algo que se deba hacer como un hábito, pero al mismo tiempo, hay ocasiones en las que puedes pasar 20 minutos escribiendo un código que puede ser clasificado como sucio o 4 horas refactorizar mucho código para hacerlo bien. En el mundo de los negocios, a veces, 20 minutos es todo lo que está disponible para hacer el trabajo y, cuando se enfrentan a plazos, la única opción es rápida y sucia.

Yo mismo he estado en ambos extremos de esto, he tenido que corregir el código sucio y he tenido que escribir el mío para solucionar las limitaciones de un sistema en el que estaba desarrollando. Yo diría que tenía confianza en el código que escribí porque a pesar de que estaba sucio y un poco pirateado a veces me aseguré de que estuviera completamente probado y que tuviera un montón de errores incorporados, por lo que si algo fallaba no destruiría el resto del sistema. p>

Cuando miramos hacia abajo a estos programadores rápidos y sucios, necesitamos recordar una cosa, un cliente generalmente no paga hasta que tenga el producto, si se envía y entra en las pruebas de UAT y encuentra los errores de código rápido y sucio. es mucho menos probable que se retiren cuando tengan un producto casi en funcionamiento enfrente de ellos, sin embargo, si no tienen nada y les está diciendo "lo tendrá pronto, solo estamos reparando x" o "se retrasó porque nosotros Tuve que ponerte a trabajar perfectamente "es más probable que se rindan y se vayan con un competidor.

¡Por supuesto, como lo demuestra esta imagen, nadie debe subestimar el peligro de un código rápido y sucio!

No creo que debas comenzar a ir por ese camino. Rápido y sucio puede darte el beneficio temporal de terminar más rápido, pero siempre pagas diez veces por hacer esto al final.

En mi opinión, aprender a juzgar el código Q & D para determinar si es correcto no es una habilidad que valga la pena desarrollar porque es solo una mala práctica. He aquí por qué:

No creo que "rápido y sucio" y "mejores prácticas" vayan de la mano. Muchos programadores (yo incluido) han generado código rápido y sucio como resultado de un sesgo en las restricciones triples . Cuando tuve que hacerlo, por lo general fue el resultado de un aumento en el alcance combinado con una fecha límite cada vez más cercana. Sabía que el código en el que estaba ingresando era chupado, pero escupía salidas apropiadas dado un conjunto de entradas. Muy importante para nuestros grupos de interés, enviamos a tiempo.

Un vistazo al Informe de CHAOS original deja bastante claro que Q & D no es una buena idea y eliminará el presupuesto más adelante (ya sea en mantenimiento o durante la expansión). Aprender a juzgar si el código Q & amp es correcto es una pérdida de tiempo. Como dijo Peter Drucker, "No hay nada tan inútil como hacer de manera eficiente lo que no se debe hacer en absoluto".

  

No puedo saber si mi nuevo código es correcto si está demasiado sucio.

"Sucio" significa diferentes cosas para diferentes personas. Para mí, principalmente significa confiar en cosas en las que sabe que probablemente no debería confiar, pero en las que también sabe que puede esperar trabajar en el corto plazo. Ejemplos: suponiendo que un botón tiene 20 píxeles de alto en lugar de calcular la altura; codificar de forma rígida una dirección IP en lugar de resolver un nombre; contar con una matriz que se ordenará porque sabe que lo está, aunque el método que proporciona la matriz no lo garantiza.

El código sucio es frágil. Puedes probarlo y saber que funciona ahora , pero es una buena apuesta que se romperá en algún momento en el futuro (o bien obligar a todos a caminar sobre cáscaras de huevo por temor a romperlo).

A riesgo de sonar un poco controvertido, yo diría que nadie realmente SABE que su código es 100% correcto y 100% sin error. Incluso cuando tiene una cobertura de prueba realmente buena y está aplicando rigurosamente las buenas prácticas de BDD / TDD, aún puede desarrollar código que contenga errores, y sí, ¡incluso puede contener efectos secundarios!

El solo hecho de escribir el código y suponer que funciona implica un exceso de confianza por parte del desarrollador de las propias capacidades del desarrollador, y que cuando surjan problemas (lo que inevitablemente hará) el esfuerzo de depurar y mantener el código será costoso, especialmente si otro desarrollador necesita mantener el código más adelante. La verdadera diferencia se logra mediante la aplicación de buenas prácticas de ingeniería de software, lo que garantiza que pueda tener una confianza real en que su código funcionará la mayor parte del tiempo y que, si encuentra un error, es más probable que sea más fácil de depurar. y mucho menos costoso de cambiar y mantener independientemente de la persona que trabaje en ese código más adelante.

El punto saliente es que el código bien factorizado y bien probado permitirá a OTROS tener confianza en su código, que en la mayoría de los casos es más importante que su propia confianza.

Si el código sucio está bien probado, puede ser confiable. El problema es que la prueba de unidad del código sucio suele ser muy difícil y engorroso. Es por eso que TDD es tan bueno; Revela y elimina la suciedad y los olores. Además, las pruebas unitarias son a menudo lo primero que sufre de presión en el tiempo. Entonces, si el hombre más limpio alguna vez hizo el código más limpio que jamás había hecho, todavía no confiaría ni un poco, si omitiera las pruebas de la unidad debido a la presión del tiempo.

Los buenos programadores (Quick & Dirty y otros) no tienen la arrogancia de asumir que lo han entendido bien. Suponen que todos los sistemas grandes tienen errores y fallas, pero que en algún momento se pueden probar y revisar lo suficientemente bien como para tener un riesgo suficientemente bajo o un costo de falla suficientemente bajo como para que el código pueda enviarse.

Entonces, ¿por qué hacen estos, llamados Quick & Sucio, programadores, ¿existen? Mi hipótesis es la selección darwiniana. Los programadores que envían rápidamente códigos viables, ocasionalmente envían antes de que la competencia se envíe, o el presupuesto se agote, o la empresa quiebre. Por lo tanto, sus compañías todavía están en el negocio, empleando nuevos programadores para quejarse del desastre que se debe limpiar. El llamado código limpio también se envía, pero no lo suficientemente diferente para conducir Quick & Los codificadores sucios en la extinción.

Es probable que uno piense que una parte no óptima de un código no puede hacer ninguna diferencia, debido a la corta vida útil, al poco impacto en los negocios o al poco tiempo para hacerlo. La respuesta correcta es que realmente no sabes. Cada vez que escucho a alguien decir que "esta es una característica pequeña" o "hagámoslo lo más rápido y sencillo posible" y no dedique suficiente tiempo a pensar en el diseño correcto, las únicas dos cosas que realmente ocurren son:

1-) El proyecto es más grande y la motivación del equipo es menor, trabajando en un código lleno de "puntadas". En ese caso, el proyecto será probable a un carril rápido hacia el caos.

2-) Se sabe que el proyecto no es una solución óptima y su uso comienza a ser desalentado, en favor de una nueva solución o una refactorización que sea tan costosa como una nueva solución.

Intenta siempre hacer el mejor código que puedas. Si no tiene suficiente tiempo, explique por qué necesita más. No te arriesgues con trabajos mal hechos. Sé siempre un mejor profesional. Nadie puede castigarte por esto si eres razonable. Si lo hacen, no es donde debería preocuparse trabajar.

Discuta con la persona mayor y evalúe el impacto de las fallas, si las hay. Por ejemplo, una situación en la que puede arreglar las tomas sucias 1 día y un código robusto requiere un cambio de diseño y arquitectura que puede llevar entre 4 y 6 meses + tiempo de validación adicional para validar completamente todos los flujos de trabajo que se vieron afectados con el cambio de diseño.

También debemos tomar una decisión basada en las prioridades de Time + Capacity + en la lista. Una buena discusión en el equipo con personas mayores o personas con mayor experiencia puede ayudar a tomar la decisión que mejor se adapte al equipo y a su entrega.

El código limpio es el primer y más importante enfoque donde el código sucio guarda las escaladas, las decisiones de los clientes en marcha y en contra, los topes de los espectáculos, la reputación de la organización en juego y muchos más en los que el código sucio se convierte en algo limpio código.