Como desarrolladores, a menudo escuchamos frases clichés lanzadas como «No te repitas». Tomamos ideas como esta y corremos con ellas, a veces un poco demasiado lejos.

Retroceder y evaluar por qué hacemos estas cosas es útil. Así que hoy, veamos una ideología alternativa a la programación SECA.

DRY se define (de acuerdo con Wikipedia) como:

Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema.

Algo de esto puede ser un poco pedante, pero puede ser útil cuando se considera algo como esto. Vamos a desglosar las partes del fraseo allí.

Cada pieza

¿Qué es «cada pieza»? ¿Nunca podemos repetir un nombre de variable? ¿Una entidad HTML?

Ok, ok. Así que podemos repetir <div> sin mucho problema y no creo que nadie se ofenda por ello. Pero esto plantea la pregunta: ¿cuándo decidimos que algo se ha convertido en una «pieza de conocimiento»? En React, un buen ejemplo podría ser un componente, pero ¿es PrimaryButton y SecondaryButton o significa una clase generalizada Button? La respuesta generalmente se considera que es «Lo que elija su organización», pero esto aún puede dejar un poco de ambigüedad en torno a lo que elegimos abstraer.

conocimiento

Este es otro punto ambiguo – ¿qué definimos como conocimiento? Considere un elemento de botón con estilo que use algunas clases atómicas y Reaccione. Si un desarrollador senior tarda 10 segundos en crear, es posible que no considere que vale la pena abstraer ese conocimiento. Pero para un desarrollador más joven que no conoce bien el sistema, ese conocimiento podría ser una buena abstracción. De lo contrario, podrían tener que buscar las clases, recordar cómo funcionan los botones y averiguar la sintaxis de un onClick. El conocimiento es relativo y usarlo en una definición añade ambigüedad.

Actualización: Xander dejó el siguiente comentario a continuación. Creo que ese artículo hace un gran trabajo al explicar lo que debería significar» conocimiento».

Solo quería dejar esto aquí para las personas que estén interesadas.

«DRY se trata de Conocimiento, la duplicación de código no es el problema.»
verraes.net/2014/08/dry-is-about-k…

representación única, inequívoca y autorizada

Una representación «única» deja mucho que desear. Desde la perspectiva de un ingeniero de devops, una sola representación podría ser una aplicación completa que necesita implementar. Para un desarrollador de frontend, eso podría ser un componente. Y para un desarrollador de backend, que podría ser un método en una clase o un punto final de API. ¿Dónde se traza la línea?

También tenemos la palabra «inequívoca», pero como acabo de señalar, el resto de esta oración define más ambigüedad. «Autoritativo» tiene sentido: su código SECO debe definir exactamente lo que hace y ser fiel a esa definición. Sin embargo, eso no se limita explícitamente al código SECO.

system

Finalmente, tenemos el «sistema» mundial , que vuelve a la declaración «individual» que discutimos hace un segundo. ¿Qué es un «sistema»? En React, puede ser un componente o una acción/componente/reductor Redux. En el software en contenedores, podríamos estar hablando de un pod completo o de una sola instancia.

Al final del día, DRY all to a menudo promueve la preoptimización, lo que es innecesario y, a veces, en realidad daña su capacidad para escribir código. A veces es más difícil modificar un componente abstraído para que se ajuste a un caso de uso específico. Agregas mucha complejidad o descompones ese componente en algo nuevo, que no es súper SECO. No puedes conocer todos los casos de uso de tu componente desde el primer día.

Una alternativa: Escribir todo dos veces la programación (HÚMEDA)

En su lugar, propongo la programación HÚMEDA. Para mí, la definición sería:

Puedes preguntarte » ¿No he escrito esto antes?»dos veces, pero nunca tres.

Con esta definición, el enfoque se aleja de la optimización prematura y en su lugar le permite repetir código similar un par de veces. También cambia el enfoque a una reacción más visceral. Le permite tomar decisiones basadas en el caso de uso exacto que está viendo. Si está creando una aplicación web, probablemente desee abstraer sus botones en un componente, porque va a usar muchos de ellos. Pero si hay una sola página que tiene un estilo especial (¿tal vez una página de precios?), entonces no tienes que preocuparte demasiado por abstraer los componentes de esa página. De hecho, bajo este sistema, si necesita una nueva página que sea similar a esa página especial, simplemente puede copiar/pegar y cambiar el código que necesita. Sin embargo, en el momento en que eso sucede una tercera vez, es hora de pasar un poco de tiempo abstrayendo las partes que se pueden abstraer.

También añadiría esta estipulación (tanto para la programación en HÚMEDO como en SECO):