![Simplicidad en la entrega de software](https://3042464.fs1.hubspotusercontent-na1.net/hub/3042464/hubfs/Open%20Graph%20Images/OG%20-%20Why%20keeping%20it%20simple%20is%20good%20for%20software%20delivery.jpg?width=528&height=528&name=OG%20-%20Why%20keeping%20it%20simple%20is%20good%20for%20software%20delivery.jpg)
- Por Laurence Lord
- ·
- Publicado 26 Aug 2024
Simplicidad en la entrega de software
KISS (keep-it-stupidly-simple principle) es uno de los primeros principios que se presentaron a los desarrolladores de software. Es un mantra que..
Si en vez de leer prefieres escuchar, dale al play.
Hace poco tuiteé que el TDD no puede conducir a un buen diseño si no sabemos qué aspecto tiene un buen diseño. También me refería a la necesidad de enseñar el diseño antes que el TDD (o al menos, al mismo tiempo). Este tuit condujo a una discusión con J.B. Rainsberger, Ron Jeffries y algunos otros. J.B. y yo terminamos teniendo una conversación en vivo en Hangout on Air más tarde.
Si revisas muchas de mis charlas, blogs e incluso mi libro, encontrarás múltiples ocasiones en las que digo que el TDD es una herramienta de diseño. Entonces, ¿qué ha cambiado? ¿Por qué ya no digo lo mismo?
Después de prestar más atención a mi forma de trabajar y a la de muchos otros desarrolladores, me he dado cuenta de que no son muchos los que impulsan un buen diseño a través de TDD. Aunque me encanta el ritmo RED-GREEN-REFACTORING, tener un paso de "refactorización" no es suficiente para llamar al TDD una herramienta de diseño.
El TDD no prescribe cómo deberías diseñar. Lo que hace es preguntarte constantemente: "¿Estás seguro de esto?, ¿es suficientemente bueno?, ¿puedes mejorarlo?". Esta molestia (o recordatorio constante de mirar tu diseño y buscar posibles mejoras) es importante, pero no suficiente.
En mi opinión, el TDD es un flujo de trabajo de desarrollo de software que proporciona muchos beneficios, incluyendo el recordatorio constante de buscar mejoras en el código. Lo que significa hacer mi código mejor, no es parte de TDD.
Ah, sí... Pero no. No me estoy olvidando de ellas. Las 4 Reglas de Diseño Simple NO son parte de TDD y aquí estoy hablando exclusivamente de TDD. Las 4 Reglas de Diseño Simple son normalmente las directrices de diseño que muchos expertos en TDD utilizan (incluyéndome a mí, entre otras técnicas) durante la fase de refactorización.
Las 4 Reglas del Diseño Simple es una de las muchas directrices de diseño que tenemos disponibles. SOLID y el Domain-Driven Design son otras. Más principios y patrones de diseño también están disponibles como buenas directrices. Estas son las cosas que necesitamos tener en nuestra mente durante la fase de "refactorización". O, poniéndolo de otra manera, tener una buena comprensión de las directrices de diseño existentes es lo que te llevará a un mejor diseño.
TDD es un flujo de trabajo (no una herramienta de diseño) en el que durante la fase de refactorización se aplican los conocimientos existentes sobre diseño de software combinados con técnicas de diseño que pueden ayudar a conseguir un diseño mejor.
Hay dos estilos principales de TDD con diferencias significativas entre ellos, principalmente en lo que respecta al diseño.
El enfoque clasicista es el enfoque original de TDD creado por Kent Beck. También se conoce como la Escuela de Detroit de TDD.
Outside-In TDD, también conocido como London School o mockist, es un estilo de TDD desarrollado y adoptado por algunos de los primeros practicantes de XP en Londres. Posteriormente inspiró la creación de BDD.
¿Qué estilo de TDD debemos utilizar? Ambos. Todas. Son sólo herramientas y, como tales, deben usarse según las necesidades. Los practicantes experimentados de TDD saltan de un estilo a otro sin preocuparse nunca de qué estilo están utilizando.
Hay dos tipos de diseño: macro y micro diseño. El micro diseño es lo que hacemos mientras probamos el código, principalmente utilizando el enfoque clasicista. El macro diseño va más allá de la función que estamos implementando. Se trata de cómo modelamos nuestro dominio a un nivel mucho más alto, cómo dividimos nuestra aplicación, capas, servicios, etc. El macro diseño nos ayuda con la organización general de la aplicación y proporciona vías para que los equipos y los desarrolladores trabajen en paralelo sin pisarse unos a otros. El macro diseño se refiere a la forma en que la empresa ve la aplicación y se suelen utilizar técnicas como el Domain-Driven Design. El macro diseño también ayuda a la coherencia en toda la aplicación. TDD no le ayudará con el macro diseño.
El macro diseño se suele tener en cuenta cuando se utiliza el Outside-In TDD, pero el Outside-In por sí solo no es suficiente para definir el macro diseño de una aplicación.
A lo largo de los años he visto muchas aplicaciones que han sido impulsadas por pruebas y seguían siendo un dolor de cabeza para trabajar. De acuerdo, admito que eran significativamente mejores que la mayoría de las aplicaciones legacy que no tenían pruebas que tenía que mantener antes.
Cualquier desarrollador puede hacer un desastre independientemente de si está escribiendo pruebas o no. Los desarrolladores también pueden hacer pruebas malas independientemente del estilo TDD que estén utilizando.
TDD no es una herramienta de diseño. Es un flujo de trabajo de desarrollo de software que tiene indicaciones para mejorar el código en su ciclo de vida.
En estas indicaciones (escribir pruebas y refactorizar), los desarrolladores necesitan conocer algunas pautas de diseño (4 Reglas de Diseño Simple, Domain Driven Design, SOLID, Patrones, Ley de Demeter, Tell, Don't Ask, POLA/S, Diseño por Contrato, Feature Envy, cohesión, acoplamiento, Principio de Abstracción Equilibrada, etc) para mejorar su código. Sólo decir refactorización no es suficiente para llamar a TDD una herramienta de diseño.
Muchos desarrolladores culpan al TDD y a los mocks de ralentizarlos. Acaban abandonando TDD porque les cuesta conseguir el resultado que quieren. En mi opinión, ningún desarrollador lucha realmente por entender el ciclo de vida RED-GREEN-REFACTOR. Lo que les cuesta es diseñar bien el software.
Lo bueno de TDD es que nos pregunta constantemente "¿Puedes mejorar tu código? ¿Ves lo difícil que se está volviendo probar esta clase? Bien, lo has hecho funcionar. Aquí está tu barra verde. Ahora, hazlo mejor". Además de eso, estás por tu cuenta.
El TDD se hace mucho más fácil cuando entendemos cómo es un buen diseño. Por esta razón, hemos recopilado recursos útiles para que te adentres en el mundo del TDD. Practicar y comprender la gran cantidad de directrices de diseño disponibles hará que el TDD sea mucho más fácil y útil. También reducirá su curva de aprendizaje y, con suerte, aumentará su adopción.
Los extremos son malos. Estamos pasando del BDUF (Big Design Up Front) a no diseñar en absoluto. Tirar a la basura nuestros conocimientos de diseño es un error. Claro que no debemos volver a la época oscura y sobredimensionar todo, pero pensar que sólo debemos centrarnos en el micro diseño también es un error. Si estás trabajando por tu cuenta, haciendo unas pocas katas, o trabajando en una pequeña aplicación, entonces sí, haz lo que quieras. Pero si formas parte de un equipo más grande desarrollando algo que es significativamente mayor que una kata, le harás un favor a tu equipo si prestas más atención al macro diseño y a cómo estructurar tu código.
KISS (keep-it-stupidly-simple principle) es uno de los primeros principios que se presentaron a los desarrolladores de software. Es un mantra que..
A veces, los detalles que parecen insignificantes a simple vista pueden desencadenar consecuencias sorprendentes y desproporcionadas. En el..
Contar con equipos productivos y felices es bueno para los negocios. Los equipos de desarrollo son una de las inversiones más caras para la mayoría..
Suscríbete a nuestra newsletter para que podamos hacerte llegar recomendaciones de expertos y casos prácticos inspiradores