La artesanía del código limpio E-Book

Robert C. Martin

• Herausgeber: ANAYA MULTIMEDIA
• Kategorie: Wissenschaft und neue Technologien
• Serie: TÍTULOS ESPECIALES
• Sprache: Spanisch

Seitenzahl: 444

Veröffentlichungsjahr: 2022

Beschreibung

Cómo escribir código del que se sienta orgulloso... todos los días En La artesanía del código limpio el legendario Robert C. Martin ('Uncle Bob') ha escrito los principios que definen la profesión (y el arte) del desarrollo de software. Uncle Bob reúne las disciplinas, los estándares y la ética que necesita para entregar un software sólido y efectivo y para estar orgulloso de todo el software que escribe. Robert Martin, el autor de los best sellers Código limpio, El limpiador de código, Arquitectura limpia y Desarrollo ágil esencial ofrece una perspectiva pragmática, técnica y prescriptiva de las disciplinas que forman los cimientos de la artesanía de software. Explica los estándares, mostrando cómo las expectativas que el mundo tiene sobre los desarrolladores difieren a menudo de las que tienen ellos mismos, y nos ayuda a sincronizarlas. Bob termina con la ética de la profesión del programador, describiendo las promesas fundamentales que todos los desarrolladores deberían hacer a sus colegas, a sus usuarios y, sobre todo, a sí mismos. Con las aportaciones de Uncle Bob, todos los programadores y sus directores pueden entregar de manera consistente código que genera confianza en vez de socavarla, confianza entre los usuarios y entre las sociedades que dependen del software para su supervivencia: * Avanzar hacia la Estrella Polar de la verdadera artesanía de software: el estado de saber cómo programar bien. * Orientación práctica y específica para aplicar cinco disciplinas esenciales: desarrollo guiado por pruebas, refactorización, diseño simple, programación colaborativa y pruebas de aceptación. * Cómo los desarrolladores y los equipos pueden fomentar la productividad, la calidad y el valor. * El verdadero significado de la integridad y el trabajo en equipo entre programadores, y diez promesas específicas que todo profesional del software debería hacer.

Leseprobe

En memoria de Mike Beedle

Agradecimientos

Gracias a mis intrépidos reseñadores: Damon Poole, Eric Crichlow, Heather Kanser, Tim Ottinger, Jeff Langr y Stacia Viscardi. Me salvaron de muchos pasos en falso.

Gracias también a Julie Phifer, Chris Zahn, Menka Mehta, Carol Lallier y todos aquellos en Pearson que trabajan sin descanso para conseguir que estos libros funcionen tan bien.

Como siempre, gracias a mi creativa y talentosa ilustradora, Jennifer Kohnke. Sus dibujos siempre me hacen reír.

Y, por supuesto, gracias a mi encantadora esposa y mi maravillosa familia.

Sobre el autor

Robert C. Martin (Uncle Bob) escribió su primera línea de código a los 12 años en 1964. Trabaja como programador desde 1970. Es cofundador de cleancoders.com, que ofrece formación mediante vídeos en línea para desarrolladores de software, y fundador de Uncle Bob Consulting LLC, que ofrece servicios de asesoría en software, formación y desarrollo de habilidades a corporaciones importantes de todo el mundo. Trabajó como "maestro artesano" en 8th Light Inc., una consultoría de software con base en Chicago.

Ha publicado docenas de artículos en varias revistas profesionales y es orador habitual en conferencias y ferias internacionales. También es el creador de la aclamada serie de vídeos educativos de cleancoders.com.

Además, ha escrito y editado múltiples libros, entre los que se incluyen los siguientes:

•Designing Object-Oriented C++ Applications Using the Booch Method.

•Patterns Languages of Program Design 3.

•More C++ Gems.

•La programación extrema en la práctica.

•Agile Software Development: Principles, Patterns, and Practices.

•UML para programadores Java.

•Código limpio.

•El limpiador de código.

•Arquitectura limpia. Guía para especialistas en la estructura y el diseño de software.

•Desarrollo ágil esencial. Vuelta a las raíces.

Líder de la industria de desarrollo de software, el señor Martin trabajó durante tres años como redactor jefe de la revista C++ Report y fue el primer presidente de la Alianza Ágil.

Índice de contenidos

Agradecimientos

Sobre el autor

Prólogo

Prefacio

Sobre el término "artesanía"

Sobre el Único camino verdadero

Introducción al libro

Para usted

Para la sociedad

La estructura de este libro

Nota para jefes

Vídeos

Imágenes y referencias

1. Artesanía

Parte I. Las disciplinas

Programación Extrema

El círculo de la vida

Desarrollo guiado por pruebas

La refactorización

Diseño simple

Programación colaborativa

Pruebas de aceptación

2. Desarrollo guiado por pruebas (TDD)

Panorama general

Software

Las tres leyes del TDD

La cuarta ley

Conceptos básicos

Ejemplos simples

Stack

Factores primos

La partida de bolos

Conclusión

3. TDD avanzado

Ordenamiento 1

Ordenamiento 2

Atascarse

Arrange Act Assert

Llega el BDD

Máquina de estados finitos

Otra vez el BDD

Dobles de pruebas

Dummy

Stub

Spy

Mock

Fake

El principio de incertidumbre del TDD

Londres frente a Chicago

El problema de la certeza

Londres

Chicago

Síntesis

Arquitectura

Conclusión

4. Diseño de pruebas

Probar bases de datos

Probar GUI

Entrada de GUI

Patrones de pruebas

Test-specific subclass

Self-Shunt

Humble Object

Diseño de pruebas

El problema de las pruebas frágiles

La correspondencia uno a uno

Romper la correspondencia

El videoclub

Especificidad frente a generalidad

Premisa de prioridad de transformación

{} Nulo

Nulo Constante

Constante Variable

Incondicional Selección

Valor Lista

Sentencia Recursividad

Selección Iteración

Valor Valor mutado

Ejemplo: Fibonacci

La premisa de prioridad de transformación

Conclusión

5. Refactorización

¿Qué es la refactorización?

El kit de herramientas básico

Cambiar nombre

Extraer método

Extraer variable

Extraer campo

El cubo de Rubik

Las disciplinas

Pruebas

Pruebas rápidas

Romper todas las correspondencias uno a uno profundas

Refactorice continuamente

Refactorice sin piedad

¡Que sigan pasándose las pruebas!

Déjese una salida

Conclusión

6. Diseño simple

Yagni

Cubierto por pruebas

Cobertura

Un objetivo asintótico

¿Diseño?

Pero hay más

Maximizar la expresión

La abstracción subyacente

Pruebas: la otra mitad del problema

Minimizar la duplicación

Duplicación accidental

Minimizar el tamaño

Diseño simple

7. Programación colaborativa

8. Pruebas de aceptación

La disciplina

La construcción continua

Parte II. Los estándares

Su nuevo director de tecnología

9. Productividad

Nunca enviaremos c**a

Adaptabilidad barata

Siempre estaremos listos

Productividad estable

10. Calidad

Mejora continua

Competencia sin miedo

Calidad extrema

No le echamos el muerto a QA

La enfermedad de QA

QA no encontrará nada

Automatización de pruebas

Pruebas automatizadas e interfaces de usuario

Probar la interfaz de usuario

11. Valor

Nos cubrimos unos a otros

Estimaciones honestas

Debe decir "no"

Aprendizaje agresivo continuo

Enseñanza

Parte III. La ética

El primer programador

Setenta y cinco años

Empollones y salvadores

Modelos a imitar y villanos

Gobernamos el mundo

Catástrofes

El juramento

12. Daño

Primero, no cause daño

No causar daño a la sociedad

No causar daño a la función

No causar daño a la estructura

Soft

Pruebas

El mejor trabajo

Hacerlo bien

¿Qué es una buena estructura?

La matriz de Eisenhower

Programadores como partes interesadas

Lo mejor

Prueba repetible

Dijkstra

Demostrar la corrección

Programación estructurada

Descomposición funcional

Desarrollo guiado por pruebas

13. Integridad

Ciclos pequeños

La historia del control del código fuente

Git

Ciclos cortos

Integración continua

Ramas frente a toggles

Despliegue continuo

Construcción continua

Mejora incansable

Cobertura de las pruebas

Prueba de mutaciones

Estabilidad semántica

Limpieza

Creaciones

Mantener una productividad alta

Viscosidad

Gestionar las distracciones

Gestión del tiempo

14. Trabajo en equipo

Trabajar como un equipo

Oficina abierta/virtual

Estimar de forma honesta y justa

Mentiras

Honestidad, exactitud, precisión

Historia 1: Vectores

Historia 2: pCCU

La lección

Exactitud

Precisión

Agregación

Honestidad

Respeto

Nunca deje de aprender

Créditos

Me acuerdo de cuando conocí a Uncle Bob en la primavera de 2003, poco después de que Scrum se introdujese en nuestra empresa y nuestros equipos de tecnología. Como ScrumMaster escéptica y novata, recuerdo escuchar a Bob hablarnos del desarrollo guiado por pruebas y de una herramienta llamada FitNesse y haber pensado: "¿Para qué querríamos escribir pruebas que fallan primero? ¿No se supone que las pruebas vienen después de la programación?".

A menudo, me iba rascándome la cabeza, igual que muchos de mis compañeros de equipo y, aun así, a día de hoy todavía recuerdo con claridad el entusiasmo palpable de Bob por la artesanía del código como si hubiese sido ayer.

Recuerdo lo directo que fue un día cuando echó un vistazo a nuestra lista de tareas para bugs y nos preguntó por qué narices tomábamos decisiones tan malas sobre sistemas de software que en realidad no eran nuestros: "Estos sistemas son activos de las empresas, no vuestros propios activos personales".

Su pasión despertó nuestra curiosidad y, un año y medio después, habíamos refactorizado nuestro trabajo a una cobertura de pruebas automatizadas de hasta el 80 por ciento y una base de código limpio que hacía que nos resultase mucho más fácil pivotar, lo que generaba clientes mucho más felices, y también equipos más felices. Después de eso, avanzábamos a toda velocidad, usando nuestra definición de "acabado" como una armadura para protegernos de los siempre acechantes duendes del código; habíamos aprendido, básicamente, a protegernos de nosotros mismos. Con el tiempo, le cogimos cariño a Uncle Bob, que llegó a parecernos un verdadero tío, un hombre cálido, decidido y valiente que nos ayudaría a aprender a no dejarnos pisotear y a hacer lo correcto.

Mientras los tíos Bob de algunos niños les enseñaban a montar en bici o a pescar, el nuestro nos enseñaba a no comprometer nuestra integridad y, todavía hoy, la habilidad y el deseo de enfrentarme a cualquier situación con valor y curiosidad han sido las mejores lecciones de mi carrera.

Las primeras lecciones de Bob me acompañaron en mi viaje cuando empecé mi andadura en el mundo como entrenadora de metodología ágil y enseguida me di cuenta de que los mejores equipos de desarrollo de producto determinaban cómo utilizar sus mejores prácticas para sus contextos exclusivos, para sus clientes específicos, en sus respectivas industrias.

Recordé las lecciones de Bob cuando observé que las mejores herramientas de desarrollo del mundo solo son tan buenas como los humanos que las utilizan, los equipos que averiguaban cuáles eran las mejores aplicaciones de estas herramientas dentro de sus propios dominios. Me di cuenta de que, sí, vale, los equipos pueden lograr porcentajes altos de cobertura de las pruebas unitarias o ir marcando casillas y cumplir con la métrica, solo para descubrir que un gran porcentaje de esas pruebas son defectuosas: se cumple con la métrica, pero no se entrega valor.

Los mejores equipos no necesitaban preocuparse por las métricas; tenían objetivos, disciplina, orgullo y responsabilidad (y, en todos los casos, las métricas hablaban por sí solas). La artesanía del código limpio entrelaza todas estas lecciones y principios creando ejemplos de código prácticos y experiencias que ilustran la diferencia entre escribir algo para cumplir un plazo y crear realmente algo que sea sostenible para el futuro.

La artesanía del código limpio nos recuerda que nunca debemos conformarnos con menos, que tenemos que caminar por el mundo con una competencia valiente. Este libro, como un viejo amigo, le recordará lo que importa, lo que funciona, lo que no, lo que genera riesgos y lo que los disminuye.

Estas lecciones son atemporales. Puede que descubra que ya practica algunas de las técnicas explicadas y estoy segura de que encontrará algo nuevo o, al menos, algo que abandonó porque en algún momento tuvo que ceder ante fechas límite u otras presiones en su carrera. Si acaba de llegar al mundo del desarrollo (ya sea la parte empresarial o la tecnológica), aprenderá del mejor, e incluso los más experimentados y curtidos en mil batallas encontrarán formas de mejorar.

Quizá este libro le ayude a encontrar su pasión de nuevo, a renovar su deseo por mejorar su habilidad o reencauzar su energía a buscar la perfección, sin importar los obstáculos que encuentre en su camino.

Los desarrolladores de software dominan el mundo y Uncle Bob está aquí otra vez para recordarnos la disciplina profesional de aquellos con semejante poder. Retoma las cosas donde las dejó con Código limpio; puesto que los desarrolladores de software escriben literalmente las reglas de la humanidad, Uncle Bob nos recuerda que debemos mantener un código ético estricto, una responsabilidad para saber qué hace el código, cómo lo usa la gente y dónde se rompe. Los errores de software cuestan a la gente su sustento y su vida.

El software influye en la forma en que pensamos, las decisiones que tomamos y, como resultado de la inteligencia artificial y el análisis predictivo, influye en el comportamiento social y de las masas. Por tanto, debemos ser responsables y actuar con mucho cuidado y empatía; la salud y el bienestar de las personas dependen de ello. Uncle Bob nos ayuda a enfrentarnos a esta responsabilidad y convertirnos en los profesionales que la sociedad espera, y exige, que seamos.

Como el Manifiesto Ágil se acerca a su vigésimo aniversario en el momento de escribir este prólogo, este libro es una oportunidad perfecta para volver a lo básico: un recordatorio oportuno y humilde de la complejidad cada vez mayor de nuestro mundo de la programación y de cómo debemos al legado de la humanidad, y a nosotros mismos, practicar un desarrollo ético. Tómese su tiempo para leer La artesanía del código limpio. Empápese de sus principios. Practíquelos. Mejórelos. Enseñe a otros. Tenga este libro siempre a mano. Deje que se convierta en un viejo amigo (su tío Bob, su guía) a medida que avanza por este mundo con curiosidad y valor.

—Stacia Heimgartner Viscardi, CST & Agile Mentor

Antes de empezar, hay dos asuntos que debemos tratar para garantizar que usted, querido lector, entiende el marco de referencia en el que se presenta este libro.

Sobre el término "artesanía"

El comienzo del siglo XXI ha estado marcado por cierta controversia respecto al lenguaje. Quienes pertenecemos a la industria del software hemos protagonizado parte de esta controversia. Un término que se ha señalado como un fracaso a la hora de ser inclusivo es "artesano".

He pensado bastante en este asunto y he hablado con muchas personas con opiniones distintas, y he llegado a la conclusión de que no hay un término mejor para utilizar en el contexto de este libro.

Se barajaron alternativas a "artesano", como "persona artesana", "oficial de artesanía" y "artífice", entre otras, pero ninguno de esos términos tiene el peso histórico de "artesano", y dicho peso es importante para este mensaje.

"Artesano" nos hace pensar en una persona muy habilidosa y dotada en una actividad concreta, alguien que está a gusto con sus herramientas y su oficio, que se enorgullece de su trabajo y que hace que podamos esperar que se comporte con la dignidad y profesionalidad de su vocación.

Puede que haya quien no esté de acuerdo con mi decisión. Entiendo por qué podría darse el caso. Solo espero que nadie lo interprete como un intento de ser excluyente de ninguna manera, ya que esa no es en absoluto mi intención.

Sobre el Único camino verdadero

Cuando lea La artesanía del código limpio, puede que tenga la sensación de que este es el "Único camino verdadero" a la artesanía. Puede que sea así para mí, pero no tiene por qué serlo para usted. Le ofrezco este libro como ejemplo de mi camino. Por supuesto, usted tendrá que elegir el suyo.

¿Necesitaremos al final un "Único camino verdadero"? No lo sé. Quizá. Como leerá en estas páginas, la presión para que haya una definición estricta de una profesión del software está aumentando. Puede que seamos capaces de admitir muchos caminos diferentes, dependiendo de la criticidad del software que se está creando. Pero, como verá en este libro, puede que no sea tan fácil separar el software crítico del que no lo es.

De una cosa estoy seguro. Los días de los "Jueces"1 se han acabado. Ya no basta con que un programador haga lo que es correcto a su parecer. Habrá disciplinas, estándares y ética. La decisión que tenemos hoy ante nosotros es si los definiremos nosotros, los programadores, o si nos los impondrán aquellos que no nos conocen.

Introducción al libro

Este libro está escrito para programadores y para jefes de programadores. Pero, en otro sentido, está escrito para toda la sociedad humana, porque somos nosotros, los programadores, los que nos hemos encontrado sin darnos cuenta en el mismísimo eje de esa sociedad.

Para usted

Si es un programador con muchos años de experiencia, es probable que conozca la satisfacción por desplegar un sistema que funcione. Se siente cierto orgullo por haber sido parte de ese logro. Está orgulloso de que su sistema salga al mundo.

Pero ¿está orgulloso de la forma en que consiguió que ese sistema saliese al mundo? ¿Es el orgullo de haber acabado o el orgullo por la calidad del trabajo? ¿Está orgulloso de que el sistema se haya desplegado o de la forma en que ha construido ese sistema?

Cuando llega a casa después de un duro día escribiendo código, ¿se mira en el espejo y dice "buen trabajo hoy" o tiene que darse una ducha?

Demasiados de nosotros nos sentimos sucios al final del día. Demasiados de nosotros nos sentimos atrapados y obligados a hacer un trabajo mediocre. Demasiados de nosotros sentimos que la baja calidad es lo que se espera y que es necesaria para que la velocidad sea alta. Demasiados de nosotros pensamos que la productividad y la calidad son inversamente proporcionales.

En este libro, trato de acabar con esa mentalidad. Es un libro sobre cómo trabajar bien, sobre cómo hacer un buen trabajo. Describe las disciplinas y las prácticas que todo programador debería conocer para trabajar rápido, ser productivo y estar orgulloso de lo que escribe cada día.

Para la sociedad

El siglo XXI marca la primera vez en la historia de la humanidad en que nuestra sociedad ha pasado a ser dependiente, para su supervivencia, de una tecnología que no ha adquirido prácticamente nada de disciplina o control. El software ha invadido todas las facetas de la vida moderna, desde la preparación de nuestro café por la mañana hasta nuestro entretenimiento vespertino, desde lavar la ropa a conducir nuestros coches, desde conectarnos en una red de alcance mundial a dividirnos a nivel social y político. No hay literalmente ningún aspecto de la vida en el mundo moderno que no esté dominado por el software. Y, aun así, los que creamos ese software somos poco más que un grupo variopinto de chapuceros que apenas tienen idea de lo que están haciendo.

Si los programadores tuviésemos un entendimiento mejor de lo que hacemos, ¿los resultados de los caucus de Iowa en 2020 hubiesen estado listos cuando se prometió? ¿Habrían muerto 346 personas en dos accidentes de aviones 737 Max? ¿Habría perdido Knight Capital Group 460 millones de dólares en 45 minutos? ¿Habrían perdido la vida 89 personas por aceleraciones no deseadas de sus Toyota?

Cada cinco años, el número de programadores en el mundo se duplica. A estos programadores se les enseña muy poco sobre su oficio. Se les muestran herramientas, se les dan unos pocos proyectos de juguete para desarrollar y después se les mete en un grupo de trabajadores que crece de forma exponencial para que respondan a una demanda que crece de manera exponencial para que haya más y más software. Todos los días, el castillo de naipes que llamamos software se introduce con mayor profundidad en nuestra infraestructura, nuestras instituciones, nuestros gobiernos y nuestras vidas. Y cada día el riesgo de catástrofe crece.

¿A qué catástrofe me refiero? No es el colapso de nuestra civilización ni la disolución repentina de todos los sistemas de software a la vez. El castillo de naipes que se espera que se venga abajo no está compuesto por los sistemas de software en sí mismos, sino que lo que está en riesgo son los frágiles cimientos de la confianza del público.

Si hay demasiados incidentes más del 737 Max, de las aceleraciones no deseadas de Toyota, de los escándalos de la EPA y Volkswagen California o de los incidentes de los caucus de Iowa (demasiados casos más de fallos o mal funcionamiento de software de perfil alto), la falta de disciplina, ética y estándares en nuestro campo se convertirá en el centro de la ira de un público furioso y desconfiado. Y entonces llegarán las regulaciones: regulaciones que ninguno de nosotros debería querer, regulaciones que paralizarán nuestra capacidad para explorar y expandir con libertad el oficio del desarrollo de software, regulaciones que supondrán restricciones severas sobre el crecimiento de nuestra tecnología y nuestra economía.

El objetivo de este libro no es detener la carrera apresurada hacia una adopción del software cada vez mayor ni ralentizar la tasa de producción de software. Esos objetivos serían malgastar esfuerzos. Nuestra sociedad necesita software y lo obtendrá cueste lo que cueste. Intentar acabar con esa necesidad no impedirá la catástrofe acechante de la confianza del público.

El objetivo de este libro es más bien inculcar en los desarrolladores de software y sus jefes la necesidad de que haya una disciplina y enseñarles las disciplinas, los estándares y la ética que son más efectivos a la hora de maximizar su capacidad para producir software robusto, a prueba de fallos y efectivo. Cambiar la manera en que trabajamos los programadores, aumentando nuestra disciplina, ética y estándares, es la única forma de apuntalar el castillo de naipes e impedir que se derrumbe.

La estructura de este libro

Este libro se divide en tres partes que describen tres niveles: disciplinas, estándares y ética.

Las disciplinas son el nivel más bajo. Esta parte del libro es pragmática, técnica y preceptiva. Programadores de todo tipo se beneficiarán de leer y entender esta parte. En sus páginas hay varias referencias a vídeos. Estos vídeos muestran el ritmo de las disciplinas de desarrollo guiado por pruebas y refactorización en tiempo real. Las páginas escritas del libro tratan de capturar también ese ritmo, pero nada funciona tan bien como los vídeos para ese propósito.

Los estándares son el nivel medio. Esta sección esboza las expectativas que tiene el mundo sobre nuestra profesión. Es una buena sección para que la lean los jefes, para que sepan qué esperar de los desarrolladores profesionales.

La ética es el nivel más alto. Esta sección describe el contexto ético de la profesión de programar. Lo hace en forma de juramento o conjunto de promesas. Está mezclada con gran parte de discusión histórica y filosófica. Deberían leerla tanto programadores como jefes.

Nota para jefes

Estas páginas contienen mucha información que le resultará beneficiosa. También contiene bastante información técnica que probablemente no necesite. Mi consejo es que lea la introducción de cada capítulo y deje de leer cuando el contenido se vuelva más técnico de lo que necesita. Después, pase al siguiente capítulo y comience de nuevo.

Asegúrese de leer la parte II, "Los estándares", y la parte III, "La ética".

Asegúrese de leer la introducción de cada una de las cinco disciplinas.

Vídeos

Este libro incluye vídeos complementarios en inglés para los capítulos 2 y 3 sobre desarrollo guiado por pruebas. Puede ver el funcionamiento de los ejemplos de código al ir leyendo el libro junto con estas demostraciones en vídeo. Estos vídeos se encuentran disponibles en la página web de Anaya Multimedia (http://www.anayamultimedia.es). Usando el buscador de esta página web, podrá localizar fácilmente la ficha de este libro y, desde ahí, descargarlos haciendo clic en el enlace Complementos.

•Capítulo 2:

•Stack (89,0 MB .mp4)

•Prime Factors (54,5 MB .mp4)

•Bowling Game (123,8 MB .mp4)

•Capítulo 3:

•SORT 1 (90,5 MB .mp4)

•SORT 2 (163,3 MB .mp4)

Imágenes y referencias

•Ilustraciones de Jennifer Kohnke.

•Portada de cubierta: Tom Cross/iStockphoto LP/Guetty Images.

•Página 6: Foto del autor por cortesía de Robert C. Martin.

•Página 28: "Necesitaremos una gran cantidad . . . lo que estamos haciendo". A.M. Turing’s ACE Report of 1946 and Other Papers. Vol. 10, "In the Charles Babbage Institute Reprint Series for the History of Computing" (B.E. Carpenter, B.W. Doran, eds.). The MIT Press, 1986.

•Página 76: Ilustración de Angela Brooks.

•Página 207: "No vas a necesitarlo". Jeffries, Ron, Ann Anderson y Chet Hendrickson. Extreme Programming Installed. Addison-Wesley, 2001.

•Página 253: "Necesitaremos . . . trabajo de este tipo por realizar". A.M. Turing’s ACE Report of 1946 and Other Papers. Vol. 10, "In the Charles Babbage Institute Reprint Series for the History of Computing" (B.E. Carpenter, B.W. Doran, eds.). The MIT Press, 1986.

•Página 253: "Una de nuestras dificultades . . . lo que estamos haciendo". A.M. Turing’s ACE Report of 1946 and Other Papers. Vol. 10, "In the Charles Babbage Institute Reprint Series for the History of Computing" (B.E. Carpenter, B.W. Doran, eds.). The MIT Press, 1986.

•Página 260: " Fueron un par de . . . por alguna razón". El director ejecutivo de Volkswagen en Norteamérica Michael Horn antes de testificar ante el Comité de Energía y Comercio de la Cámara en Washington, 8 de octubre, 2015.

•Página 276: "Tengo dos . . . nunca son urgentes". En un discurso en la Segunda Asamblea del Consejo Mundial de Iglesias en 1954, el expresidente de EE. UU. Dwight D. Eisenhower, que estaba citando al Dr. J. Roscoe Miller, presidente de la Universidad Northwestern.

•Página 277: Dwight D. Eisenhower, Presidente de Estados Unidos. Retrato oficial de 29 de mayo de 1959. White House - Eisenhower Presidential Library.

•Página 283: " Por supuesto, no . . . ningún tamaño en absoluto". Edsger W. Dijkstra: Notes on Structured Programming in Pursuit of Simplicity; the manuscripts of Edsger W. Dijkstra, Ed. Texas; 1969-1970; http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF.

•Página 291: Foto por cortesía de Robert C. Martin.

•Página 293: Foto por cortesía de Robert C. Martin.

1. Referencia al Libro de los Jueces del Antiguo Testamento.

 

El sueño de volar es casi tan antiguo como la humanidad. El antiguo mito griego que describe el vuelo de Dédalo e Ícaro data de alrededor del año 1550 a.e.c. En los milenios siguientes, numerosas almas valientes, aunque insensatas, han atado a sus cuerpos artilugios toscos y han saltado desde acantilados y torres hacia su perdición en busca de ese sueño.

Las cosas empezaron a cambiar hace unos quinientos años cuando Leonardo Da Vinci dibujó bocetos de máquinas que, aunque en realidad no podían volar, mostraban cierto pensamiento razonado. Fue Da Vinci quien se dio cuenta de que el vuelo podría ser posible porque la resistencia del aire actúa en ambas direcciones. La resistencia causada por empujar hacia abajo en el aire crea una elevación en la misma cantidad. Este es el mecanismo por el cual vuelan todos los aviones modernos.

Las ideas de Da Vinci se perdieron hasta mediados del siglo XVIII, pero, entonces, comenzó una exploración casi frenética de la posibilidad de volar. Los siglos XVIII y XIX fueron una época de investigación y experimentación aeronáuticas intensas. Se construyeron, probaron, descartaron y mejoraron prototipos sin alimentación. La ciencia de la aeronáutica empezó a tomar forma. Se definieron y entendieron las fuerzas de sustentación, arrastre, empuje y gravedad. Algunos valientes hicieron incluso pruebas.

Y algunos chocaron y murieron.

A finales del siglo XVIII y durante la mitad del siglo siguiente, Sir George Cayley, el padre de la aerodinámica moderna, creó aparatos experimentales, prototipos y modelos a tamaño real, que culminaron en el primer vuelo tripulado de un planeador.

Y aun así algunos chocaron y murieron.

Después llegó la era del vapor y la posibilidad de vuelos tripulados con alimentación. Se realizaron docenas de prototipos y experimentos. Científicos y entusiastas se unieron al grupo de personas que exploraban el potencial de un vuelo. En 1890, Clément Ader voló 50 metros en una máquina de dos motores alimentada por vapor.

Y aun así algunos chocaron y murieron.

Pero el motor de combustión interna fue el que lo cambió todo. Con toda probabilidad, el primer vuelo tripulado con alimentación y controlado lo realizó en 1901 Gustave Whitehead, pero fueron los hermanos Wright quienes, el 17 de diciembre de 1903, en Kill Devil Hills, Carolina de Norte, efectuaron el primer vuelo tripulado realmente sostenido, con alimentación y controlado de una máquina más pesada que el aire.

Y aun así algunos chocaron y murieron.

Pero el mundo cambió de la noche a la mañana. Once años después, en 1914, había biplanos combatiendo en el aire sobre Europa.

Y aunque muchos chocaron y murieron a causa del fuego enemigo, una cantidad similar chocó y murió solo aprendiendo a volar. Puede que los principios del vuelo se hubiesen dominado, pero la técnica del vuelo apenas se comprendía.

Dos décadas después, los terribles cazas y bombarderos de la Segunda Guerra Mundial sembraban el caos en Francia y Alemania. Volaban a altitudes extremas. Estaban llenos de armas. Tenían un poder destructivo devastador.

Durante la guerra se perdieron 65.000 aviones americanos, pero solo 23.000 de ellos se perdieron en combate. Los pilotos volaban y morían en la batalla, pero, con mayor frecuencia, volaban y morían cuando nadie les estaba disparando. Aún no sabíamos cómo volar.

Otra década vio la aparición del avión a reacción, la rotura de la barrera del sonido y la explosión de las aerolíneas comerciales y el tráfico aéreo civil. Fue el comienzo de la era de los jets, cuando la gente pudiente (la llamada jet set) podía ir de ciudad en ciudad y de país en país en cuestión de horas.

Y aun así estos aviones de pasajeros se hacían pedazos y caían del cielo en cantidades alarmantes. Todavía había muchas cosas que no entendíamos acerca de cómo fabricar y hacer volar un avión.

Llegamos a finales de los años cincuenta. Los Boeing 707 llevaban pasajeros de acá para allá por todo el mundo a finales de la década. Dos décadas después aparecería el primer jumbo de fuselaje ancho, el 747.

La aeronáutica y los viajes aéreos se asentaron y se convirtieron en el modo de viajar más seguro y eficiente de la historia del mundo. Se tardó mucho tiempo, y costó muchas vidas, pero por fin habíamos aprendido a construir y pilotar aviones de manera segura.2

Chesley Sullenberger nació en 1951 en Denison, Texas. Era un hijo de la era de los jets. Aprendió a volar a los dieciséis años y acabó pilotando F4 Phantoms para la Fuerza Aérea de EE. UU. Se convirtió en piloto de US Airways en 1980.

El 15 de enero de 2009, nada más salir del aeropuerto de LaGuardia, su Airbus A320, en el que llevaba a 155 pasajeros, se topó con una bandada de gansos y perdió ambos motores. El capitán Sullenberger, sirviéndose de su experiencia de más de 20.000 horas en el aire, pilotó el avión dañado hasta realizar un amerizaje en el río Hudson y, gracias a su habilidad totalmente imbatible, salvó a todas y cada una de esas 155 personas. El capitán Sullenberger brillaba en su oficio. El capitán Sullenberger era un artesano.

El sueño de una gestión de datos y una computación rápidas y fiables es, casi con total seguridad, tan antiguo como la humanidad. Contar con los dedos, con palitos y abalorios se remonta a hace miles de años. La gente ya estaba fabricando y usando ábacos hace más de 4.000 años. Se usaban dispositivos mecánicos para predecir el movimiento de las estrellas y los planetas hace 2.000 años. Las reglas de cálculo se inventaron hace aproximadamente 400 años.

A principios del siglo XIX, Charles Babbage empezó a construir máquinas de cálculo accionadas mediante una manivela. Eran verdaderas computadoras digitales con memoria y procesamiento aritmético, pero eran difíciles de fabricar con la tecnología de metalistería de la época y, aunque construyó algunos prototipos, no fueron un éxito comercial.

A mediados del siglo XIX, Babbage intentó crear una máquina mucho más potente. Se trataría de una máquina alimentada por vapor y capaz de ejecutar auténticos programas. La llamó Máquina analítica.

La hija de Lord Byron, Ada, condesa de Lovelace, tradujo las notas de una conferencia de Babbage y se dio cuenta de un hecho que, por lo visto, no se le había ocurrido a nadie más en esa época: los números en una computadora no tienen por qué representar números, sino que pueden representar cosas del mundo real. Por esa idea, la llaman con frecuencia la primera programadora del mundo.

Los problemas de la metalistería precisa siguieron frustrando a Babbage y, al final, su proyecto fracasó. No se hicieron más progresos en las computadoras digitales durante el resto del siglo XIX y principios del XX. En ese tiempo, sin embargo, las computadoras analógicas metálicas lograron su máximo apogeo.

En 1936, Alan Turing demostró que no hay una manera general de probar que una ecuación diofántica3 dada tiene soluciones. Construyó esta prueba imaginando un ordenador digital sencillo, aunque infinito, y después demostrando que había números que este ordenador no podía calcular. Como consecuencia de esta prueba, inventó las máquinas de estados finitos, el lenguaje de máquina, el lenguaje simbólico, las macros y las subrutinas primitivas. Inventó lo que hoy denominaríamos software.

Casi al mismo tiempo, Alonzo Church construyó una prueba completamente diferente para el mismo problema y, en consecuencia, desarrolló el cálculo lambda, el concepto central de la programación funcional.

En 1941, Konrad Zuse creó el primer ordenador digital programable electromecánico, el Z3. Contaba con más de 2.000 relés y una frecuencia de reloj de entre 5 y 10 Hz. La máquina usaba aritmética binaria organizada en palabras de 22 bits.

Durante la Segunda Guerra Mundial, Turing fue reclutado para ayudar a los "cerebritos" de Bletchley Park a descifrar los códigos de la Enigma alemana. La máquina Enigma era un simple ordenador digital que aleatorizaba los caracteres de mensajes textuales que solían emitirse mediante radiotelegrafía. Turing ayudó en la construcción de un motor de búsqueda digital electromecánico para encontrar las claves de esos códigos.

Después de la guerra, Turing fue fundamental en la creación y programación de uno de los primeros ordenadores de tubos de vacío electrónicos del mundo, el motor de computación automática (Automatic Computing Engine, ACE). El prototipo original usaba 1.000 tubos de vacío y manipulaba números binarios a una velocidad de un millón de bits por segundo.

En 1947, después de escribir algunos programas para esta máquina e investigar sus capacidades, Turing dio una conferencia en la que hizo estas clarividentes afirmaciones:

Necesitaremos una gran cantidad de matemáticos con capacidad [para poner los problemas] en una forma adecuada para la computación.

Una de nuestras dificultades será el mantenimiento de una disciplina apropiada, de manera que no perdamos de vista lo que estamos haciendo.

Y el mundo cambió de la noche a la mañana.

En solo unos años, se había desarrollado la memoria central. La posibilidad de tener cientos de miles, por no decir millones, de bits de memoria accesibles en microsegundos se hizo realidad. Al mismo tiempo, la producción masiva de tubos de vacío hizo que los ordenadores fuesen más baratos y fiables. La producción masiva limitada estaba convirtiéndose en una realidad. Para 1960, IBM había vendido 140 ordenadores del modelo 70x, que eran enormes máquinas con tubos de vacío que valían millones de dólares. Turing había programado su máquina en binario, pero todo el mundo se daba cuenta de que eso era poco práctico. En 1949, Grace Hopper había acuñado el término "compilador" y para 1952 había creado el primero: A-0. A finales de 1953, John Backus presentó la primera especificación de FORTRAN. ALGOL y LISP ya habían aparecido para 1958.

John Bardeen, Walter Brattain y William Shockley crearon el primer transistor funcional en 1947. Entraron en el mundo de los ordenadores en 1953. Sustituir tubos de vacío por transistores cambió el panorama por completo. Los ordenadores se volvieron más pequeños, rápidos y baratos, y mucho más fiables.

Para 1965, IBM había producido 10.000 ordenadores del modelo 1401. Se alquilaban por 2.500 dólares al mes, algo asequible para negocios medianos. Esos negocios necesitaban programadores, así que la demanda de programadores empezó a acelerar.

¿Quién estaba programando esas máquinas? No había carreras universitarias. Nadie iba a la escuela a aprender a programar en 1965. Estos programadores procedían de las empresas. Eran personas maduras que llevaban tiempo trabajando en esos negocios. Tenían treinta y tantos, cuarenta y tantos, cincuenta y tantos.

Para 1966, IBM estaba produciendo 1.000 ordenadores del modelo 360 al mes. Las empresas nunca tenían suficiente. Estas máquinas tenían tamaños de memoria que llegaba a 64 kB y más. Podían ejecutar cientos de miles de instrucciones por segundo.

Ese mismo año, trabajando en un Univac 1107 en el Centro Noruego de Computación, Ole-Johan Dahl y Kristen Nygaard inventaron Simula 67, una extensión de ALGOL. Fue el primer lenguaje orientado a objetos.

¡La conferencia de Alan Turing había sido solo dos décadas antes!

Dos años después, en marzo de 1968, Edsger Dijkstra escribió su famosa carta a la revista Communications of the ACM (CACM). El editor tituló esa carta "Go To Statement Considered Harmful" (La sentencia goto, considerada perjudicial).4 Había nacido la programación estructurada.

En 1972, en Bell Labs en Nueva Jersey, Ken Thompson y Dennis Ritchie estaban entre proyectos. Pidieron tiempo en un PDP 7 de un equipo de proyecto diferente e inventaron UNIX y C.

Entonces aumentó el ritmo a velocidades de vértigo. Voy a darle unas cuantas fechas clave. Para cada una, pregúntese cuántos ordenadores hay en el mundo. Cuántos programadores hay en el mundo y de dónde vinieron esos programadores.

1970—Digital Equipment Corporation había producido 50.000 ordenadores PDP-8 desde 1965.

1970—Winston Royce escribió el artículo sobre "el modelo en cascada", "Managing the Development of Large Software Systems".

1971—Intel lanzó el microordenador de un solo chip 4004.

1974—Intel lanzó el microordenador de un solo chip 8080.

1977—Apple lanzó el Apple II.

1979—Motorola lanzó el 68000, un microordenador de un solo chip de 16 bits.

1980—Bjarne Stroustrup inventó C con Clases (un preprocesador que hace que C se parezca a Simula).

1980—Alan Kay inventó Smalltalk.

1981—IBM lanzó el ordenador personal IBM PC.

1983—Apple lanzó el Macintosh 128K.

1983—Stroustrup rebautizó C con Clases como C++.

1985—El Departamento de Defensa de EE. UU. adoptó el modelo en cascada como proceso oficial de desarrollo de software (DOD-STD-2167A).

1986—Stroustrup publicó El lenguaje de programación C++ (Addison-Wesley).

1991—Grady Booch publicó Object-Oriented Design with Applications (Benjamin/Cummings).

1991—James Gosling inventó Java (llamado Oak en aquel momento).

1991—Guido Van Rossum lanzó Python.

1995—Erich Gamma, Richard Helm, John Vlissides y Ralph Johnson escribieron Patrones de diseño: Elementos de software orientado a objetos reutilizable (Addison-Wesley).

1995—Yukihiro Matsumoto lanzó Ruby.

1995—Brendan Eich creó JavaScript.

1996—Sun Microsystems lanzó Java.

1999—Microsoft inventó C#/.NET (entonces llamado Cool).

2000—Y2K! El Efecto 2000.

2001—Se escribió el Manifiesto Ágil.

Entre 1970 y 2000, la frecuencia de reloj de los ordenadores aumentó en tres órdenes de magnitud. La densidad se incrementó en cuatro órdenes de magnitud. El espacio de disco aumentó en seis o siete órdenes de magnitud. Los costes habían bajado de dólares por bit a dólares por gigabit. El cambio en el hardware es difícil de visualizar, pero solo con sumar todos los órdenes de magnitud que he mencionado llegamos a alrededor de treinta órdenes de magnitud de incremento de la capacidad.

Y todo esto solo unos cincuenta años después de la conferencia de Alan Turing.

¿Cuántos programadores hay ahora? ¿Cuántas líneas de código se han escrito? ¿Cómo de bueno es ese código?

Compare esta cronología con la de la aeronáutica. ¿Ve la similitud? ¿Ve el incremento gradual en la teoría, las prisas y los fracasos de los entusiastas, el aumento gradual de la competencia? ¿Las décadas de no saber lo que estamos haciendo?

Y, ahora que nuestra sociedad depende, para su propia existencia, de nuestras habilidades, ¿tenemos a los Sullenbergers que necesita la sociedad? ¿Hemos preparado a los programadores que entienden su oficio con tanta profundidad como los pilotos de las aerolíneas entienden el suyo? ¿Tenemos a los artesanos que, sin duda, vamos a requerir?

La artesanía es el estado de saber cómo hacer algo bien y es el resultado de un buen tutelaje y mucha experiencia. Hasta hace poco, la industria del software tenía muy poco de ambas. Los programadores tendían a no quedarse como programadores mucho tiempo, porque veían la programación como un trampolín hacia la dirección. Eso significaba que había muy pocos programadores que adquiriesen suficiente experiencia para enseñar el oficio a otros. Para empeorar las cosas, el número de programadores nuevos que entran al campo se duplica cada cinco años, más o menos, lo que hace que la ratio de programadores experimentados sea muy baja.

El resultado ha sido que la mayoría de los programadores nunca aprenden las disciplinas, estándares y ética que podrían definir su oficio. Durante su carrera relativamente corta escribiendo código, permanecen como novatos que no llegan a aprendices. Y eso, por supuesto, significa que gran parte del código producido por esos programadores inexpertos es de calidad inferior, con mala estructura, inseguro, con fallos y, por lo general, un desastre.

En este libro, describo los estándares, disciplinas y ética que creo que todo programador debería conocer y seguir para adquirir de forma gradual el conocimiento y la habilidad que su oficio requiere en realidad.

2 A pesar del 737 Max.

3 Ecuaciones de enteros.

4 Edsger W. Dijkstra, "Go To Statement Considered Harmful", Communications of the ACM 11, n.º 3 (1968).

 

¿Qué es una disciplina? Es un conjunto de reglas que se compone de dos partes: una esencial y una arbitraria. La parte esencial es la que da a la disciplina su poder; es la razón por la que existe. La parte arbitraria es la que da a la disciplina su forma y su sustancia. Sin la parte arbitraria, la disciplina no puede existir.

Por ejemplo, los cirujanos se lavan las manos antes de una operación. Si pudiese verlo, se daría cuenta de que el lavado de manos se hace de una forma muy particular. El cirujano no se lava las manos enjabonándolas y poniéndolas debajo del chorro de agua sin más, como haríamos usted y yo, sino que sigue una disciplina ritualizada para el lavado de manos. Una rutina así que he visto es, en parte, como sigue:

•Utiliza el jabón adecuado.

•Utiliza el cepillo adecuado.

•Para cada dedo, usa:

•Diez frotamientos por la parte superior.

•Diez frotamientos por el lado izquierdo.

•Diez frotamientos por la parte inferior.

•Diez frotamientos por el lado derecho.

•Diez frotamientos por la uña.

•Y así sucesivamente.

La parte esencial de la disciplina debería ser obvia. Las manos del cirujano deben estar muy limpias. Pero ¿se da cuenta de cuál es la parte arbitraria? ¿Por qué diez frotamientos, en vez de ocho o doce? ¿Por qué dividir el dedo en cinco secciones? ¿Por qué no en tres o en siete?

Todo eso es arbitrario. No hay una razón real para esos números, salvo que se consideraron suficientes.

En este libro, estudiamos cinco disciplinas de artesanía de software. Algunas de ellas tienen cinco décadas, pero todas han demostrado su utilidad a lo largo de esas décadas. Sin ellas, la simple noción de "software como un arte" sería sencillamente impensable.

Cada una de estas disciplinas tiene sus propios elementos esenciales y arbitrarios. Cuando lea, puede que su mente ponga objeciones a una o más de las disciplinas. Si eso ocurre, plantéese si la objeción es acerca de los elementos esenciales de la disciplina o solo de los elementos arbitrarios. No se deje confundir por los elementos arbitrarios. Mantenga su atención sobre los elementos esenciales. Una vez que haya internalizado la esencia de cada disciplina, lo más probable es que la forma arbitraria pierda importancia.

Por ejemplo, en 1861, Ignaz Semmelweis publicó sus hallazgos derivados de la aplicación de la disciplina del lavado de manos para los médicos. Los resultados de su investigación fueron asombrosos. Fue capaz de demostrar que, cuando los médicos se lavaban las manos meticulosamente con hipoclorito cálcico antes de examinar a mujeres embarazadas, la tasa de muertes de esas mujeres a causa de la subsiguiente sepsis pasaba de ser una de cada diez a prácticamente cero.

Pero los médicos de la época no separaron la esencia de lo arbitrario cuando repasaron la disciplina propuesta por Semmelweis. El hipoclorito cálcico era la parte arbitraria. Les espantaba la inconveniencia de lavarse con lejía, así que rechazaron la evidencia de la naturaleza esencial del lavado de manos.

Pasaron muchas décadas hasta que los médicos empezaron a lavarse las manos.

Programación Extrema

En 1970, Winston Royce publicó el artículo que convirtió el proceso de desarrollo en cascada en el modelo dominante. Se necesitaron casi 30 años para enmendar ese error.

Para 1995, los expertos en software habían empezado a considerar un enfoque diferente, más progresivo. Se presentaron procesos como Scrum, el desarrollo basado en funcionalidades, el método de desarrollo de sistemas dinámicos (DSDM) y las metodologías Crystal, pero, en general, hubo muy pocos cambios en la industria.

Después, en 1999, Kent Beck publicó el libro Una explicación de la Programación Extrema (Addison-Wesley). La Programación Extrema (XP) se cimentaba en las ideas de aquellos procesos anteriores, pero añadía algo nuevo: las prácticas de ingeniería.

El entusiasmo por la XP creció de forma exponencial entre 1999 y 2001. Ese entusiasmo fue lo que engendró y guio la revolución del desarrollo ágil. Hasta el día de hoy, la XP sigue siendo el mejor definido y el más completo de todos los métodos ágiles. Las prácticas de ingeniería en su núcleo son el foco de atención de esta sección sobre las disciplinas.

El círculo de la vida

La figura I.1 muestra el círculo de la vida de Ron Jeffries, que recoge las prácticas de la XP. Las disciplinas que tratamos en este libro son las cuatro del centro y la del extremo izquierdo.

Figura I.1. El círculo de la vida; las prácticas de la XP.

Las cuatro del centro son las prácticas de ingeniería de la XP: desarrollo guiado por pruebas (Test-driven development, TDD), refactorización, diseño simple y programación en pareja (que denominaremos programación colaborativa). La práctica en el extremo izquierdo, las pruebas de aceptación, es la más técnica y centrada en la ingeniería de las prácticas de empresa de la XP.

Estas cinco prácticas están entre las disciplinas fundamentales de la artesanía de software.

Desarrollo guiado por pruebas

El desarrollo guiado por pruebas es la disciplina que actúa como eje. Sin él, las otras disciplinas son imposibles o impotentes. Por esa razón, las dos siguientes secciones que describen el TDD representan casi la mitad de las páginas de este libro y son muy técnicas. Esta organización puede parecer mal equilibrada. De hecho, a mí también me lo parece, y le di muchas vueltas a qué hacer al respecto. Sin embargo, mi conclusión es que la falta de equilibrio es una reacción al correspondiente desequilibrio dentro de nuestra industria. Hay demasiado pocos programadores que conozcan bien esta disciplina.

El TDD es la disciplina que rige la manera en que un programador trabaja sobre una base segundo a segundo. No es ni una disciplina por adelantado ni una disciplina a posteriori. El TDD se da durante el proceso y de frente. No hay forma de hacer un TDD parcial; es una disciplina de todo o nada.

La esencia de la disciplina del TDD es muy simple. Primero, vienen los ciclos pequeños y las pruebas. Las pruebas son lo primero en todo. Se escriben primero. Se limpian primero. En todas las actividades, lo primero son las pruebas. Y todas las actividades se dividen en ciclos lo más pequeños posible.

Los tiempos de los ciclos se miden en segundos, no en minutos. Se miden en caracteres, no en líneas. El bucle de feedback se cierra, de forma casi literal, en cuanto se abre.

El objetivo del TDD es crear una suite de pruebas a la que le confiaríamos nuestra vida. Si la prueba se supera, deberíamos sentirnos seguros para desplegar el código.

De todas las disciplinas, el TDD es la más onerosa y la más compleja. Es onerosa porque lo domina todo. Es lo primero y lo último en lo que pensamos. Es la limitación que cubre todo lo que hacemos. Es la gobernadora que mantiene la paz con firmeza a pesar de la presión y el estrés del entorno.

El TDD es complejo porque el código es complejo. Para cada forma de código, hay una forma correspondiente de TDD. El TDD es complejo porque las pruebas deben diseñarse para que encajen en el código sin acoplarse a él y deben cubrir casi todo y, aun así, ejecutarse en segundos. El TDD es una habilidad elaborada y compleja que es muy difícil de adquirir, pero increíblemente gratificante.

La refactorización

La refactorización es la disciplina que nos permite escribir código limpio, Refactorizar es difícil, por no decir imposible, sin el TDD.5 Por tanto, escribir código limpio es difícil o imposible sin el TDD.

La refactorización es la disciplina mediante la cual manipulamos un código con una estructura pobre para convertirlo en un código con una estructura mejor, sin afectar a su comportamiento. La última parte es crucial. Al asegurar que el comportamiento del código no se ve afectado, garantizamos que las mejoras en la estructura son seguras.

La razón por la que no limpiamos código (la razón por la que los sistemas de software se deterioran con el tiempo) es que nos da miedo que limpiar el código estropee su comportamiento. Pero, si tenemos una manera de limpiar código que sabemos que es segura, entonces limpiaremos el código y nuestros sistemas no se deteriorarán.

¿Cómo nos aseguramos de que nuestras mejoras no afecten al comportamiento? Tenemos las pruebas del TDD.

La refactorización es también una disciplina compleja porque hay muchas maneras de crear un código con una estructura pobre. Así, hay muchas estrategias para limpiar ese código. Además, cada una de esas estrategias debe encajar sin fricciones y de forma concurrente en el ciclo con "pruebas primero" del TDD. Lo cierto es que estas dos disciplinas están entrelazadas de forma tan profunda que son prácticamente inseparables. Es casi imposible refactorizar sin TDD, y es prácticamente imposible practicar el TDD sin practicar la refactorización.

Diseño simple

La vida en la Tierra podría describirse hablando de capas. En la superior está la ecología, el estudio de sistemas de cosas vivas. Debajo, está la fisiología, el estudio de los mecanismos internos de la vida. La siguiente capa podría ser la microbiología, el estudio de las células, los ácidos nucleicos, las proteínas y otros sistemas macromoleculares. Estos, a su vez, están descritos por la ciencia de la química, que a su vez está descrita por la mecánica cuántica.

Si ampliamos esa analogía a la programación, si el TDD es la mecánica cuántica de la programación, entonces la refactorización es la química y el diseño simple es la microbiología. Continuando esa analogía, los principios SOLID, el diseño orientado a objetos y la programación funcional son la fisiología, y la arquitectura es la ecología de la programación.

El diseño simple es casi imposible sin la refactorización. De hecho, es el objetivo final de la refactorización, y esta es el único medio práctico para lograr ese objetivo. Ese objetivo es la producción de gránulos atómicos simples de diseño que encajan bien en las estructuras más grandes de programas, sistemas y aplicaciones.

El diseño simple no es una disciplina compleja. Está guiado por cuatro reglas muy sencillas. Sin embargo, a diferencia del TDD y la refactorización, el diseño simple es una disciplina imprecisa. Depende del juicio y la experiencia. Si se hace bien, es el indicio que separa a un aprendiz que conoce las normas de un oficial veterano que entiende los principios. Es el comienzo de lo que Michael Feathers ha denominado "sentido de diseño".

Programación colaborativa

La programación colaborativa es la disciplina y el arte de trabajar juntos en un equipo de software. Incluye subdisciplinas como la programación en pareja, mob programming, revisiones de código y lluvias de ideas. La programación colaborativa implica a todos los miembros del equipo, tanto programadores como no programadores. Es el medio principal por el que compartimos conocimientos, aseguramos la consistencia y solidificamos el equipo como un conjunto funcional.

De todas las disciplinas, la programación colaborativa es la menos técnica y la menos preceptiva. Sin embargo, puede que sea la más importante de las cinco disciplinas, puesto que crear un equipo efectivo es algo valioso y poco habitual.

Pruebas de aceptación

Las pruebas de aceptación son la disciplina que une al equipo de desarrollo de software con la empresa. El objetivo empresarial es la especificación de los comportamientos deseados del sistema. Estos comportamientos se codifican como pruebas. Si esas pruebas se pasan, el sistema se comporta como se ha especificado.

Los representantes de la empresa deben poder leer y escribir estas pruebas. Escribir y leer estas pruebas y ver cómo se pasan es lo que hace que la empresa sepa lo que hace el software y que hace lo que la empresa necesita que haga.

5 Puede que haya otras disciplinas capaces de soportar la refactorización, además del TDD. El flujo de trabajo Test && commit || revert de Kent Beck es una posibilidad. Sin embargo, en el momento de escribir esto, no ha disfrutado de un nivel elevado de adopción y sigue siendo más una curiosidad académica.

 

Nuestra explicación sobre el desarrollo guiado por pruebas abarca dos capítulos. Primero, tratamos los conceptos básicos del TDD de una manera muy técnica y detallada. En este capítulo aprenderá la disciplina paso a paso. El capítulo ofrece una gran cantidad de código para leer y también varios vídeos en inglés para ver.

En el capítulo 3, "TDD avanzado", hablaremos de muchas de las trampas y misterios a los que se enfrentan los novatos del TDD, como las bases de datos y las interfaces gráficas de usuario. También exploramos los principios de diseño que guían un buen diseño de pruebas y los patrones de diseño para las pruebas. Por último, investigaremos algunas posibilidades teóricas interesantes y profundas.

Panorama general

Cero. Es un número importante. Es un número del equilibrio. Cuando los dos lados de una balanza están equilibrados, el puntero de la balanza se sitúa en cero. Un átomo neutro, con el mismo número de electrones y de protones, tiene una carga de cero. La suma de las fuerzas de un puente se equilibra en cero. El cero es el número del equilibrio.

¿Alguna vez se ha preguntado por qué la cantidad de dinero en su cuenta bancaria se llama balance? Se debe a que el balance de la cuenta es la suma de todas las transacciones que han depositado o retirado dinero de esa cuenta. Pero las transacciones siempre tienen dos lados, porque mueven dinero entre cuentas.