SlideShare ist ein Scribd-Unternehmen logo
1 von 9
Clean Code
Capitulo 8 – Limites o Fronteras
Juan Felipe Ortega Lugo
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.
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).
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.
Usar código que todavía no existe.
 Separar lo conocido de lo desconocido.
 Ejemplo:
Limites Limpios
 Cambios en el código de terceros.
 Evitar conocer detalles de terceros.
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.
Gracias… .

Weitere ähnliche Inhalte

Was ist angesagt? (16)

Algoritmo y programación
Algoritmo y programaciónAlgoritmo y programación
Algoritmo y programación
 
Algoritmo, diagramas
Algoritmo, diagramasAlgoritmo, diagramas
Algoritmo, diagramas
 
Unidad#1
Unidad#1Unidad#1
Unidad#1
 
Physical computing cap 4-5
Physical computing cap 4-5Physical computing cap 4-5
Physical computing cap 4-5
 
Presentación1
Presentación1Presentación1
Presentación1
 
Programación estructurada
Programación estructuradaProgramación estructurada
Programación estructurada
 
Pseudocodigo ferro
Pseudocodigo ferroPseudocodigo ferro
Pseudocodigo ferro
 
Unidad1
Unidad1Unidad1
Unidad1
 
Action script
Action scriptAction script
Action script
 
Paradigmas de programacion
Paradigmas de programacionParadigmas de programacion
Paradigmas de programacion
 
Actionscript 3
Actionscript 3Actionscript 3
Actionscript 3
 
Unidad 02 metodología para solucionar un problema
Unidad 02   metodología para solucionar un problemaUnidad 02   metodología para solucionar un problema
Unidad 02 metodología para solucionar un problema
 
Action script
Action scriptAction script
Action script
 
Tema 10
Tema 10Tema 10
Tema 10
 
Apuntes #XPweek
Apuntes #XPweekApuntes #XPweek
Apuntes #XPweek
 
Plan3 powerpoint
Plan3 powerpointPlan3 powerpoint
Plan3 powerpoint
 

Ähnlich wie Clean code

Unidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De ProgramasUnidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De Programas
Sergio Sanchez
 
Clases De Pruebas Y Definiciones
Clases De Pruebas Y DefinicionesClases De Pruebas Y Definiciones
Clases De Pruebas Y Definiciones
alfep
 

Ähnlich wie Clean code (20)

software libre duayen
software libre duayensoftware libre duayen
software libre duayen
 
Tendencias de la informatica y su incidencia en la seguridad
Tendencias de la informatica y su incidencia en la seguridadTendencias de la informatica y su incidencia en la seguridad
Tendencias de la informatica y su incidencia en la seguridad
 
Software
SoftwareSoftware
Software
 
7iSF-4 test driver development
7iSF-4   test driver development7iSF-4   test driver development
7iSF-4 test driver development
 
Lorena bernal trabajo
Lorena bernal trabajoLorena bernal trabajo
Lorena bernal trabajo
 
Unidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De ProgramasUnidad 2.3 Prueba De Programas
Unidad 2.3 Prueba De Programas
 
Pruebas unitarias
Pruebas unitariasPruebas unitarias
Pruebas unitarias
 
Seguridad vs software libre
Seguridad vs software libreSeguridad vs software libre
Seguridad vs software libre
 
Software
SoftwareSoftware
Software
 
Software
SoftwareSoftware
Software
 
Software y tipos de software
Software y tipos de softwareSoftware y tipos de software
Software y tipos de software
 
Seguridad en Internet
Seguridad en InternetSeguridad en Internet
Seguridad en Internet
 
Clases De Pruebas Y Definiciones
Clases De Pruebas Y DefinicionesClases De Pruebas Y Definiciones
Clases De Pruebas Y Definiciones
 
6.redes pruebas de software
6.redes pruebas de software6.redes pruebas de software
6.redes pruebas de software
 
Centrales Telefónicas (PBX)
 Centrales Telefónicas (PBX)  Centrales Telefónicas (PBX)
Centrales Telefónicas (PBX)
 
software libre y software propietario
software libre y software propietariosoftware libre y software propietario
software libre y software propietario
 
1 unidad 2 trabajo.docx dal
1 unidad 2 trabajo.docx dal1 unidad 2 trabajo.docx dal
1 unidad 2 trabajo.docx dal
 
Unidad ii. tdd
Unidad ii. tddUnidad ii. tdd
Unidad ii. tdd
 
Las funciones de los sistemas operativos
Las funciones de los sistemas operativosLas funciones de los sistemas operativos
Las funciones de los sistemas operativos
 
Act 4.3 pruebas de software
Act 4.3 pruebas de softwareAct 4.3 pruebas de software
Act 4.3 pruebas de software
 

Clean code

  • 1. Clean Code Capitulo 8 – Limites o Fronteras Juan Felipe Ortega Lugo
  • 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:
  • 6. Limites Limpios  Cambios en el código de terceros.  Evitar conocer detalles de terceros.
  • 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.
  • 8.