¿Primero ordenado?

Prefacio

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

¿Qué es Tidy First?

"Tengo que cambiar este código, pero es un lío. ¿Qué debo hacer primero?"

"Quizá debería ordenar el código antes de hacer el cambio. Tal vez. Algo. ¿O tal vez no?"

Son preguntas que podrías hacerte, y si hubiera respuestas fáciles, no habría sentido la necesidad de escribir un libro para abordarlas.

Tidy First? describe:

• Cuándo ordenar el código desordenado antes de cambiar lo que computa

• Cómo ordenar el código desordenado de forma segura y eficaz

• Cómo dejar de ordenar el código desordenado

• Por qué funciona ordenar

El diseño de software es un ejercicio de relaciones humanas. En ¿Tidy First? empezamos con la proverbial persona en el espejo: con la relación del programador consigo mismo. ¿Por qué no nos tomamos tiempo para cuidarnos? ¿Nos tomamos tiempo para facilitarnos el trabajo? ¿Por qué nos metemos en la madriguera del conejo de limpiar código excluyendo el trabajo que ayudaría a nuestros usuarios?

¿Tidy First? es el siguiente paso en mi misión de ayudar a los frikis a sentirse seguros en el mundo. También es el primer paso que hay que dar cuando nos enfrentamos a un código desordenado. El diseño de software es una herramienta poderosa para aliviar el dolor en el mundo, si se utiliza bien. Mal utilizado, se convierte en un instrumento más de opresión y en un lastre para la eficacia del desarrollo de software.

¿Primero ordenado? es el primero de una serie de libros centrados en el diseño de software. Quiero hacer que el diseño de software sea accesible y valorado, así que empiezo con el tipo de diseño de software que puedes hacer por ti mismo. Los volúmenes siguientes aplicarán el diseño de software a las relaciones sanas entre los programadores de un equipo, y luego abordarán lo más importante: la relación entre la empresa y la tecnología. Pero primero, entendamos y practiquemos el diseño de software de forma que beneficie a nuestro trabajo diario.

Supongamos que tienes una gran función que contiene muchas líneas de código. Antes de cambiarla, lees ese código para entender lo que está pasando. En el proceso, ves cómo puedes dividir lógicamente el código en trozos más pequeños. Cuando extraes esos trozos, estás ordenando. Otros tipos de ordenación incluyen el uso de cláusulas de guarda, comentarios explicativos y funciones de ayuda.

Como libro, ¿Primero Ordenar? pone en práctica lo que propone: presentar estas ordenaciones en pequeños trozos y sugerir cuándo y dónde puedes aplicarlas. Así, en lugar de intentar dominar la ordenación de golpe, puedes probar algunas ordenaciones que tengan sentido para tu problema. Ordenar primero... también comienza describiendo la teoría que subyace al diseño de software: acoplamiento, cohesión, flujos de caja descontados y opcionalidad.

Audiencia

Este libro está pensado para programadores, desarrolladores principales, arquitectos de software prácticos y directores técnicos. No está vinculado a ningún lenguaje de programación, y todos los desarrolladores podrán leer y aplicar los conceptos de este libro a sus propios proyectos. Este libro asume que el lector no es nuevo en la programación en general.

Lo que aprenderás

Al final de este libro, lo entenderás:

• La diferencia fundamental entre los cambios en el comportamiento de un sistema y los cambios en su estructura

• La magia habilitadora de alternar la inversión en estructura y la inversión en comportamiento, como un programador solitario que cambia el código

• Los fundamentos de la teoría de cómo funciona el diseño de software y las fuerzas queactúan sobre él

Y serás capaz de hacerlo:

• Mejora tu propia experiencia de programación ordenando a veces primero (y a veces ordenando después).

• Empieza a hacer grandes cambios en pequeños pasos seguros.

• Prepárate para diseñar como una actividad humana con incentivos divergentes.

Estructura del Libro

¿Primero ordenado? se divide en una Introducción y tres partes:

Introducción

Empiezo con una breve descripción de mis motivaciones para escribir este libro, cómo llegué a escribirlo, a quién va dirigido y qué puedes esperar. Luego entramos de lleno.

Parte I, "Arreglos"

Una ordenación es como una pequeña refactorización en miniatura. Cada pequeño capítulo es una ordenación. Si ves código así, cámbialo por código así. Luego envíalo aproducción.

Parte II, "Gestionar"

A continuación abordaremos la gestión del proceso de ordenación. Parte de la filosofía de la ordenación es que nunca debe ser un gran problema. Nunca es algo de lo que haya que informar, hacer un seguimiento, planificar y programar. Necesitas cambiar este código, y es difícil cambiarlo porque está desordenado, así que primero lo ordenas. Incluso como parte de la actividad diaria, sigue siendo un proceso que mejora con el pensamiento.

Parte III, "Teoría"

Aquí es donde por fin puedo desplegar mis alas y profundizar en los temas que me apasionan. ¿Qué quiero decir con "el diseño de software es un ejercicio de relaciones humanas"? ¿Quiénes son esos seres humanos? ¿Cómo se satisfacen mejor sus necesidades con un mejor diseño de software? ¿Por qué cuesta tanto el software? ¿Qué podemos hacer al respecto (alerta de spoiler: diseño de software)? ¿Acoplamiento? ¿Cohesión? ¿Leyes de potencia?

Mi objetivo es que los lectores empiecen a leer por la mañana y estén diseñando mejor esa tarde. Y que después diseñen un poco mejor cada día. Muy pronto, el diseño desoftware dejará de ser el eslabón más débil de la cadena de creación de valor mediantesoftware.

¿Por qué diseño "empírico" de software?

Los debates más fuertes en el diseño de software parecen versar sobre qué diseñar:

• ¿Qué tamaño deben tener los servicios?

• ¿Qué tamaño deben tener los repositorios?

• Eventos frente a invocación explícita de servicios.

• Objetos frente a funciones frente a código imperativo.

Estos debates ocultan un desacuerdo más fundamental entre los diseñadores de software: ¿cuándo? He aquí una caricatura de los polos de este desacuerdo:

Diseño especulativo

Sabemos lo que queremos hacer a continuación, así que diseñemos para ello hoy. Será más barato diseñar ahora. Además, una vez que el software esté en producción nunca tendremos la oportunidad de diseñar, así que apilémoslo todo hoy.

Diseño reactivo

Las funciones son lo único que le importa a la gente, así que diseñemos lo menos posible hoy para poder volver a las funciones. Sólo cuando sea casi imposible añadir funciones, mejoraremos el diseño a regañadientes, y entonces sólo lo suficiente para volver a las funciones.

Aspiro a responder a la pregunta de "¿cuándo?" con "en algún punto intermedio". Cuando observamos que una determinada clase de características es difícil de añadir, diseñamos hasta que se alivia la presión. Empezamos con el diseño justo para poner en marcha los ciclos de retroalimentación:

Características

¿Qué quieren los usuarios?

Diseño

¿Cuál es la mejor forma de apoyar a los programadores para que ofrezcan esas prestaciones?

La respuesta empírica del diseño de software a la pregunta de cuándo es contingente. Diseña en algún momento cuándo puedes sacar partido del diseño. Responder a esta pregunta requiere gusto, negociación y juicio. ¿Requerir gusto y juicio es una debilidad? Claro, pero es una debilidad inevitable. El diseño especulativo y reactivo también requieren juicio, pero dan a los diseñadores de software menos herramientas con las que trabajar.

Me gusta la palabra empírico para describir este estilo porque parece aclarar la distinción que hago con los tiempos de diseño especulativo y reactivo. "Basado en, preocupado por, o verificable por la observación o la experiencia más que por la teoría o la lógica pura". Suena bastante correcto.

¿Cómo llegué a escribir Primero ordenado?

Cuando era estudiante, asistí a un curso sobre diseño de software en el que se utilizaba el libro Diseño estructurado, de Ed Yourdon (RIP) y Larry Constantine. No entendí gran cosa del libro, sobre todo porque aún no me había enfrentado a los problemas que trataba.

Avancemos 25 años hasta 2005. Ya había diseñado un montón de software. Sentía que dominaba bastante bien el diseño. Stephen Fraser organizó un panel en OOPSLA (la gran conferencia de programación orientada a objetos) para celebrar el 30 aniversario de la publicación del libro. Ed y Larry iban a formar parte del panel, junto con Rebecca Wirfs-Brock, Grady Booch, Steve McConnell y Brian Henderson-Sellers.

Si no quería salir volando del escenario, tenía deberes que hacer. Así que abrí mi amarillento ejemplar de Diseño Estructurado y empecé a leer. Horas después levanté la vista, absolutamente cautivado. Aquí estaban las leyes del movimiento de Newton, pero para el diseño de software. Estaba todo tan claro cuando salió. ¿Cómo hemos podido olvidar esa claridad como industria?

Recuerdo que el panel fue muy bien. Un momento culminante de la conferencia fue el desayuno con Ed y Larry, dos tipos extremadamente brillantes que se sentían completamente cómodos consigo mismos y con los demás. La Figura P-1 muestra las firmas que dejaron en mi libro de texto hace mucho tiempo.

Figura P-1. Inscripciones de Ed Yourdon ("¡No creas nada de lo que leas en este libro!") y Larry Constantine ("...¡incluido lo anterior!")

Por aquel entonces, el libro ya mostraba su vejez. Los ejemplos que utilizaban cinta de papel y cinta magnética ya no eran relevantes. Tampoco lo era la discusión sobre el lenguaje ensamblador frente a los nuevos lenguajes de alto nivel. Sin embargo, los conceptos básicos eran correctos. Me prometí que trasladaría ese material al público actual.

Hice varios intentos frustrados de escribir un libro de diseño de software en los años intermedios (busca "Kent Beck Responsive Design" si quieres ver en qué andaba). No fue hasta 2019 cuando, inesperadamente, tuve dos semanas de tiempo completamente libre. Decidí ver qué parte del libro podía escribir en esas dos semanas.

Diez mil palabras después, había aprendido una lección importante: no iba a ser capaz de abordar todo el diseño de software en un solo libro. Una situación que se repetía una y otra vez en lo que había redactado era este momento del diseño a pequeña escala: Tengo un código desordenado: ¿lo cambio o lo ordeno primero?

Mi experiencia escribiendo libros siempre ha sido así. Toma un tema que parezca demasiado pequeño para un libro. Escribe. Descubre que el tema es demasiado grande para un libro. Toma un trozo pequeño, demasiado pequeño. Escribe. Descubre que el trozo es demasiado grande. Repite.

Así que aquí tienes (virtualmente o de verdad) los primeros frutos de ese voto que ya dura casi 20 años. He descubierto que al debatir esa pregunta de cada hora: "¿Debo ordenar primero?". he podido tocar muchos de los temas más queridos por mi corazón de diseñadora. Espero tus comentarios y seguir profundizando en mi comprensión de todo lo que hace que el diseño de software sea divertido y valioso.

Aprendizaje en línea O'Reilly

Nota

Durante más de 40 años, O'Reilly Media ha proporcionado formación tecnológica y empresarial, conocimientos y perspectivas para ayudar a las empresas a alcanzar el éxito.

Nuestra red única de expertos e innovadores comparten sus conocimientos y experiencia a través de libros, artículos y nuestra plataforma de aprendizaje online. La plataforma de aprendizaje en línea de O'Reilly te ofrece acceso bajo demanda a cursos de formación en directo, rutas de aprendizaje en profundidad, entornos de codificación interactivos y una amplia colección de textos y vídeos de O'Reilly y de más de 200 editoriales. Para más información, visita https://oreilly.com.

Cómo contactar con nosotros

Dirige tus comentarios y preguntas sobre este libro a la editorial:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Norte
• Sebastopol, CA 95472
• 800-889-8969 (en Estados Unidos o Canadá)
• 707-829-7019 (internacional o local)
• 707-829-0104 (fax)
• [e-mail]
• https://www.oreilly.com/about/contact.html

Tenemos una página web para este libro, donde se enumeran erratas, ejemplos y cualquier información adicional. Puedes acceder a esta página en https://oreil.ly/tidy-first.

Envía un correo electrónico a [e-mail] para comentar o hacer preguntas técnicas sobre este libro.

Para noticias e información sobre nuestros libros y cursos, visita https://oreilly.com.

Encuéntranos en LinkedIn: https://linkedin.com/company/oreilly-media

Síguenos en Twitter: https://twitter.com/oreillymedia

Míranos en YouTube: https://youtube.com/oreillymedia

Agradecimientos

El "autor" de un libro es una ficción contable. Yo escribí las palabras, pero estas palabras no estarían en tus manos sin una multitud de personas. Aquí tienes algunas.

Gracias por los primeros comentarios técnicos a Anna Goodman, Matan Zruya, Jeff Carbonella, David Haley, Kelly Sutton y el resto de mis alumnos de Gusto. Gracias por los comentarios técnicos sobre el manuscrito a Maude Lemaire, Rebecca Wirfs-Brock, Vlad Khononov y Oleksii Torunov. Gracias a mis suscriptores de pago en https://tidyfirst.substack.com por regalarme tiempo para escribir y por sus comentarios sobre los capítulos a medida que los redactaba.

Gracias al experto equipo de producción de O'Reilly, que hizo que el proceso fuera lo más fluido posible: Melissa Duffield, Michele Cronin, Louise Corrigan. Gracias a Tim O'Reilly por arriesgarse con un libro corto.

Gracias a Keith Adams y Pamela Vagata por las charlas técnicas, los ánimos y algún que otro cóctel. Gracias a Susan por la mezcla adecuada de ánimos y empujones. Gracias a mis hijos, Beth, Lincoln, Lindsey, Forrest y Joëlle.

Gracias a mis mentores y colegas del diseño de software: Ward Cunningham, Martin Fowler, Ron Jeffries, Erich Gamma, David Saff y Massimo Arnoldi.

Por último, gracias a Ed Yourdan (de bendita memoria) y a Larry Constantine por averiguar todo esto hace tanto tiempo.