stringtranslate.com

No te repitas

" No te repitas " ( DRY ) es un principio de desarrollo de software cuyo objetivo es reducir la repetición de información que es probable que cambie, reemplazándola con abstracciones que tienen menos probabilidades de cambiar o utilizando la normalización de datos que evita la redundancia en primer lugar.

El principio DRY se enuncia como "Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema". El principio ha sido formulado por Andy Hunt y Dave Thomas en su libro The Pragmatic Programmer . [1] Lo aplican de forma bastante amplia para incluir esquemas de bases de datos , planes de prueba , el sistema de compilación e incluso la documentación . [2] Cuando el principio DRY se aplica con éxito, una modificación de cualquier elemento individual de un sistema no requiere un cambio en otros elementos lógicamente no relacionados. Además, todos los elementos que están relacionados lógicamente cambian de forma predecible y uniforme, y por lo tanto se mantienen sincronizados . Además de utilizar métodos y subrutinas en su código, Thomas y Hunt se basan en generadores de código , sistemas de compilación automáticos y lenguajes de script para observar el principio DRY en todas las capas.

Principio de elección única

Un caso particular de DRY es el principio de elección única . Fue definido por Bertrand Meyer como: “Siempre que un sistema de software debe soportar un conjunto de alternativas, uno y sólo un módulo en el sistema debe conocer su lista exhaustiva”. [3] Fue aplicado al diseñar Eiffel .

Alternativas

HÚMEDO

La visión opuesta a DRY se llama WET, un acrónimo que comúnmente se toma para significar escribir todo dos veces [4] (alternativamente escribir cada vez , disfrutamos escribiendo o perdemos el tiempo de todos ). Las soluciones WET son comunes en arquitecturas de múltiples niveles donde un desarrollador puede tener la tarea, por ejemplo, de agregar un campo de comentario en un formulario en una aplicación web. La cadena de texto "comentario" puede repetirse en la etiqueta, la etiqueta HTML, en un nombre de función de lectura, una variable privada, DDL de base de datos, consultas, etc. Un enfoque DRY elimina esa redundancia mediante el uso de marcos que reducen o eliminan todas esas tareas de edición excepto las más importantes, dejando la extensibilidad de agregar nuevas variables de conocimiento en un solo lugar. [5] Esta conceptualización de "WET" como una alternativa a la programación "DRY" ha existido desde al menos 2002 en el mundo Java, aunque no se sabe quién acuñó el término. [6]

Jaja

Otro enfoque de las abstracciones es el principio AHA, que significa evitar abstracciones apresuradas y que Kent C. Dodds describió como optimizar para el cambio primero y evitar la optimización prematura. [7] y fue influenciado por el principio de Sandi Metz de "preferir la duplicación a la abstracción incorrecta". [8]

La AHA se basa en la comprensión de que cuanto más invierten los ingenieros en la abstracción de un software, más perciben que el costo de esa inversión nunca se puede recuperar ( falacia del costo irrecuperable ). Por lo tanto, los ingenieros tienden a continuar iterando sobre la misma abstracción cada vez que cambia el requisito. La programación AHA supone que tanto las soluciones WET como las DRY inevitablemente crean software que es rígido y difícil de mantener. En lugar de comenzar con una abstracción, o abstraer en un número específico de duplicaciones, el software puede ser más flexible y robusto si la abstracción se realiza cuando es necesaria o cuando la duplicación en sí se ha convertido en la barrera y se sabe cómo debe funcionar la abstracción.

La programación AHA fue originalmente denominada "código húmedo" por Dodds, luego nuevamente por Daniel Bartholomae, [9] y originalmente denominada DAMP ( Don't Abstract Methods Prematurely ) por Matt Ryer. [10] Ya había un principio de programación diferente llamado DAMP ( Descriptive And Meaningful Phrases ) y descrito por Jay Fields, [11] y la comunidad se opuso al uso de MOIST, debido a la aversión cultural a la palabra húmedo . [12] Dodds pidió alternativas en Twitter y sugirió DATE como una alternativa antes de decidirse por la sugerencia de Cher Scarlett de AHA. [7] [13] [14]

Véase también

Referencias

  1. ^ Hunt, Andrew; Thomas, David (1999). El programador pragmático: de oficial a maestro (1.ª ed.). EE. UU.: Addison-Wesley. pp. 320. ISBN 978-0201616224.
  2. ^ Dave Thomas, entrevistado por Bill Venners (10 de octubre de 2003). "Ortogonalidad y el principio DRY" . Consultado el 1 de diciembre de 2006 .
  3. ^ Construcción de software orientado a objetos, 2.ª edición, página 63
  4. ^ Pai, Praseed; Xavier, Shine (31 de enero de 2017). Patrones de diseño .NET. Packt Publishing Ltd. ISBN 978-1-78646-186-5.
  5. ^ Justin Lee (8 de marzo de 2006). "DRY es para perdedores" . Consultado el 31 de agosto de 2013 .
  6. ^ Zig Zichterman (8 de agosto de 2002). "JavaOne 2002: Notas de Zig" . Consultado el 9 de enero de 2024 .
  7. ^ de Kent C. Dodds (1 de abril de 2019). "Programación AHA" . Consultado el 8 de mayo de 2021 .
  8. ^ Sandi Metz (20 de enero de 2016). "La abstracción equivocada" . Consultado el 8 de mayo de 2021 .
  9. ^ Bartholomae, Daniel (21 de agosto de 2020). "Código húmedo: por qué el código no debería estar completamente SECO". The Startup CTO . Consultado el 11 de noviembre de 2021 .
  10. ^ Haus, Ev (24 de diciembre de 2020). "Usando el código DRY, WET y DAMP". Medium . Consultado el 11 de noviembre de 2021 .
  11. ^ Fields, Jay. "Código DRY, DAMP DSL". Jay Fields' Thoughts . Consultado el 11 de noviembre de 2021 .
  12. ^ Resnick, Brian (28 de abril de 2016). "¿Por qué a tanta gente le desagrada la palabra "húmedo"? Este científico tiene una teoría". Vox Media . Consultado el 11 de noviembre de 2021 .
  13. ^ Dodds, Kent (27 de marzo de 2021). "3 minutos con Kent: primero escribe el código y luego haz la abstracción". Briefs . Consultado el 11 de noviembre de 2021 .
  14. ^ Dodds, Kent; Bostian, Emma; Nisi, Nick (30 de julio de 2021). «JS Party – Episodio n.° 186: Cómo engancharse a React». Registro de cambios . Consultado el 11 de noviembre de 2021 .

Enlaces externos