2. Clean Code
No es habitual que controlemos todo el software de nuestro sistemas. En ocasiones
adquirimos paquetes de terceros o usamos código abierto. De algún modo
debemos integrar ese código externo con el nuestro.
Tensión entre proveedor de una interfaz y un usuario de la misma.
Mayores entornos.
Funcionalidad mas especifica.
3. Explorar y aprende limites
Mayor funcionalidad <-> menos tiempo.
¿Por donde empezábamos cuando queremos utilizar código de terceros?.
Perdida de días.
Pruebas de aprendizaje (Demo).
4. Las pruebas de aprendizaje son mas que
gratuitas.
Aprender a usar y crear la prueba.
Rentables (Distintas versiones).
No hay garantía completa de 100% Integración.
Limite claro, respaldado por un conjunto de pruebas de limites para facilitar la
transición, podríamos conservar la versión mas antigua mas tiempo del necesario.
5. Usar código que todavía no existe.
Separar lo conocido de lo desconocido.
Ejemplo:
7. Conclusiones.
Los sistemas dependen de paquetes de terceros o de componentes desarrollados
por otros equipos. Hay que definir de forma clara la frontera entre el código y el
exterior para poder acomodar de forma sencilla los futuros cambios, minimizando
las partes de nuestro código que dependan de elementos externos.
Los test ayudan a experimentar con el código externo viendo cómo puede cubrir
nuestras necesidades. También permiten comprobar que las nuevas versiones de la
librería siguen cumpliendo con nuestras necesidades.
Encapsular el conocimiento adquirido a través de los test en un interfaz entre
nuestro sistema y el código de terceros permite localizar en un único punto las
modificaciones debidas a posibles cambios en código que está fuera de nuestro
control.