Esta es una traducción del artículo AHA Programming publicado por Kent C. Dodds.
DRY
DRY (acrónimo de “Don’t Repeat Yourself”), es un principio de software que Wikipedia define como:
El principio No te repitas (en inglés Don’t Repeat Yourself o DRY, también conocido como Una vez y sólo una) es una filosofía de definición de procesos que promueve la reducción de la duplicación especialmente en computación
Esta es generalmente una buena práctica a la que normalmente me suscribo (aunque menos dogmáticamente de lo que parece alentar esa definición). El mayor problema que he tenido con la duplicación de código (también conocido como copiar / pegar, es básicamente la antítesis de DRY) es descubrir un error en un lugar, solucionarlo, luego darme cuenta de que el mismo error estaba en otro lugar y tener que arreglarlo allí también.
Una vez, heredé una base de código que hacía un uso intensivo de la duplicación de código y una vez tuve que corregir un error en ocho lugares diferentes. 😱 ¡Que irritante! Resumir ese código en una función que se pudiera llamar en cualquier lugar que fuera necesario habría ayudado MUCHO.
WET
Hay otro concepto al que la gente se ha referido como programación WET, que significa “Escribe todo dos veces”. Eso es igualmente dogmático y demasiado prescriptivo. Conlin Durbin lo ha definido como:
Puedes preguntarte “¿No he escrito esto antes?” dos veces, pero nunca tres.
En ese mismo código que mencioné anteriormente, hubo una abstracción excesiva que fue incluso más dañina que la duplicación. Era código AngularJS y se usó para varios controladores AngularJS, el código pasaba this a una función que remendaria métodos y propiedades del this mejorando la instancia del controlador añadiendo ciertas habilidades. Una especie de pseudo-herencia, supongo. Fue SUPER confuso, difícil de seguir y estaba aterrorizado de hacer cambios en esa área del código.
El código se reutilizó en más de tres lugares, pero la abstracción fue tan mala que pensé que hubiese sido mejor si el código se hubiera duplicado.
AHA💡
AHA (pronunciado “¡Ajá!” Como si acabaras de hacer un descubrimiento!) es un acrónimo que obtuve de Cher Scarlett que significa:
“Avoid Hasty Abstractions” que traducido seria: “Evite las abstracciones apresuradas” EAA!
La forma en que pienso de este principio está bien descrita por Sandi Metz, quien escribió:
“prefiero la duplicación a la abstracción incorrecta”
Esta es una píldora de sabiduría que quiero que la lea de nuevo y luego leas la publicación del blog de Sandi sobre el tema: La abstracción equivocada. (en inglés) Es fantástico.
Aquí hay otro principio relacionado importante que quiero agregar:
“Primero optimice para el cambio”
Creo que la clave es que no sabemos cuál será el futuro del código. Podríamos pasar semanas optimizando el código para el rendimiento, o ideando la mejor API para nuestra nueva abstracción, solo para descubrir al día siguiente que hicimos suposiciones incorrectas y que la API necesita una reestructuración completa o la función para la que se escribió el código ya no se necesita. No lo sabemos con certeza. Todo lo que realmente podemos estar seguros es que las cosas probablemente cambiarán, y si nunca lo hacen, entonces no tocaremos el código de todos modos, así que ¿a quién le importa cómo se ve?
No me malinterpretes, no estoy sugiriendo anarquía. Solo estoy sugiriendo que debemos tener en cuenta el hecho de que realmente no sabemos qué requisitos se impondrán a nuestro código en el futuro.
Así que estoy de acuerdo con la duplicación de código hasta que se sienta bastante seguro de que conocemos todos los casos de uso de ese código duplicado. ¿Qué partes del código son diferentes que serían buenos argumentos para su función? Una vez que tenga algunos lugares donde se ejecuta ese código, los puntos en común le pedirán abstracción a gritos y estarás mejor preparado para proporcionar esa abstracción.
Sin embargo, si abstrae temprano, pensará que la función o el componente es perfecto para su caso de uso y, por lo tanto, simplemente dobla el código para que se ajuste a su nuevo caso de uso. Esto continúa varias veces hasta que la abstracción es básicamente toda su aplicación envuelta en declaraciones if y else 😂😭
Hace unos años, me contrataron para revisar la base de código de una empresa y utilicé una herramienta llamada jsinspect para identificar fragmentos de código copiado / pegado para mostrarles oportunidades de abstracción. Tenían un montón de código duplicado y, desde mi perspectiva, al mirar hacia adentro, era obvio cómo deberían verse las abstracciones.
Creo que la gran conclusión de la “Programación AHA” es que no debes ser dogmático sobre cuándo comienzas a escribir abstracciones, sino escribir la abstracción cuando te parezca correcto y no tener miedo de duplicar el código hasta que llegues allí.
Conclusión
Siento que un enfoque mesurado y pragmático de los principios del software es importante. Por eso prefiero AHA en lugar de WET o DRY. Su objetivo es ayudarlo a tener en cuenta sus abstracciones sin dar reglas estrictas sobre cuándo está o no está bien abstraer algún código en una función o módulo.
Espero que te sea de ayuda. Si te encuentras atascado en malas abstracciones, ¡anímate! ¡Sandi te da algunos buenos pasos para salir de eso! Puedes leer la publicación en su blog. (en Inglés)
¡Buena suerte!