EL PROGRAMADOR PRAGMÁTICO

El Programador Pragmático es una guía hábil y práctica que proporciona una visión y los fundamentos para ser un buen programador, aumentando su especialización y tecnicidad en el desarrollo de software moderno. El libro se publicó en octubre de 1999. Andrew Hunt abarca desde temas de responsabilidad personal y desarrollo profesional hasta técnicas de arquitectura para mantener su código flexible y fácil de adaptar y reutilizar. El libro le enseñará a luchar contra la podredumbre del software, a evitar la trampa de la duplicación de conocimientos y a hacer sus desarrollos más precisos con la automatización.

¿CÓMO NOS HA AYUDADO ESTE LIBRO?

Este libro nos ayudó a entender cómo los desarrolladores pueden convertirse en mejores programadores comprendiendo los fundamentos básicos necesarios para el éxito en el desarrollo de software. Demuestra que ser un buen programador no es sólo cuestión de habilidades técnicas. Se centra en temas prácticos como el desacoplamiento, la edición de potencia, la depuración y las pruebas, que nos ayudan a ayudar a los desarrolladores a crear mejor código para nuestros clientes y a convertirnos en consultores y miembros de equipos de grandes proyectos. El libro nos ayudó a comprender cómo utilizar nuestra experiencia para tomar decisiones más informadas tanto en nuestra vida profesional como personal.

EL LIBRO EXPLICADO EN MENOS DE 60 SEGUNDOS

El libro utiliza analogías y pequeñas historias para presentar metodologías de desarrollo y advertencias, por ejemplo, la teoría de las ventanas rotas, la historia de la sopa de piedra o la rana hirviendo. También cuenta con pequeños ejercicios para practicar sus habilidades de programación.

El programador pragmático explica que los defectos del software se manifiestan de varias formas, desde requisitos mal entendidos hasta errores de codificación. Por desgracia, los sistemas informáticos modernos siguen limitándose a hacer lo que se les dice y no lo que se quiere que hagan.

Según el libro, nadie escribe software perfecto. Así que se da por hecho que la depuración consumirá una parte importante de su día. La depuración es un tema sensible y emocional para muchos desarrolladores.

LAS TRES MEJORES CITAS

«Las herramientas amplifican su talento. Cuanto mejores sean sus herramientas y mejor sepa utilizarlas, más productivo podrá ser».

«La mayor de todas las debilidades es el miedo a parecer débil».

«El editor será una extensión de su mano; las teclas cantarán mientras cortan el texto y el pensamiento».

RESUMEN Y NOTAS DEL LIBRO

Capítulo uno: Una filosofía pragmática

1. El gato se comió mi código fuente

Asuma su responsabilidad: La responsabilidad es algo que usted acepta activamente; se dedica a garantizar que algo se ejecuta correctamente. Sin embargo, no tiene necesariamente el control directo sobre todos los aspectos. Tiene derecho a no asumir la responsabilidad de una situación inimaginable o rodeada de grandes riesgos. Cuando acepte la responsabilidad de una situación, tenga la humildad de rendir cuentas. Todo el mundo comete errores. Por lo tanto, cuando cometa uno, admítalo honestamente y trate de encontrar opciones.

2. Entropía del software

Tener una ventana rota sin reparar en casa durante un periodo considerable infunde en los ocupantes de la casa una sensación de abandono que acaba creando más daños y ruina. Lo mismo se aplica al software; un trozo de código pésimo puede provocar más daños si no se repara lo suficientemente pronto. Por lo tanto, no conviva con un código destructivo. Arréglelo en cuanto descubra un fallo. Tome alguna medida y muestre iniciativa para evitar más daños y demostrar que está al tanto de la situación.

3. Software suficientemente bueno

Suficientemente bueno no implica un código descuidado o mal producido. Todos los sistemas deben cumplir los requisitos de sus usuarios para tener éxito. Puede someterse a escribir software lo suficientemente bueno para sus usuarios, futuros mantenedores y su tranquilidad. Escribir software suficientemente bueno le hace más productivo y a sus usuarios más felices. Construir código suficientemente bueno simplemente aboga por que se permita a los usuarios participar en el proceso de decidir si lo que usted ha producido es suficientemente bueno.

Cuando construya un código suficientemente bueno, sepa cuándo parar. No arruine un programa sobresaliente con un exceso de embellecimiento y refinamiento. Siga adelante y deje que su código se mantenga por sí mismo durante un tiempo. Puede que no sea perfecto. No se preocupe: nunca podrá ser perfecto. Un buen software ahora es mejor que un software ideal dentro de un año.

Cita favorita del capítulo: « Un gran software hoy es a menudo preferible a un software perfecto mañana».

Capítulo dos: Un enfoque pragmático

1. Los males de la duplicación

Como programador, usted recopila, organiza, mantiene y aprovecha los conocimientos. Por desgracia, el aprendizaje no es constante ni fijo y cambia rápidamente. Su comprensión de un requisito puede cambiar tras una reunión con el cliente. Esto significa que usted pasa la mayor parte de su tiempo intentando mantener el código a diario. La mayoría de la gente piensa que el mantenimiento comienza cuando se lanza una aplicación, que el mantenimiento significa corregir errores y mejorar características. Esas personas se equivocan. El mantenimiento no es una actividad separada, sino una parte del proceso de desarrollo, porque los nuevos requisitos llegan a medida que usted diseña el código.

La única manera de desarrollar software de forma fiable y de hacer que sus desarrollos sean más fáciles de entender y mantener es seguir el principio DRY (Don’t Repeat Yourself): Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema.

La mayoría de las duplicidades que observamos pertenecen a una de las siguientes categorías:

• Duplicación impuesta. Siente que no tiene elección: el entorno parece exigirle una réplica.
• Duplicación involuntaria. No se da cuenta de que está duplicando información.
• Duplicación impaciente. Uno se vuelve perezoso y duplica porque parece más fácil.
• Duplicación entre desarrolladores. Varias personas de un equipo duplican una información y no se dan cuenta.

2. Reversibilidad.

Los cambios no tienen por qué ser extremos ni tan inmediatos. Pero a medida que pasa el tiempo y su proyecto avanza, puede encontrarse atrapado en una posición insostenible. El equipo del proyecto se compromete con un objetivo más pequeño con decisiones críticas, creando una versión de la realidad con menos opciones. El problema es que las decisiones críticas no son fácilmente reversibles.

Nada es para siempre, y si confía firmemente en algún hecho, casi puede garantizar que cambiará. Planifique la reversibilidad porque ninguna decisión es definitiva. Aspire a un código, una arquitectura y una integración de proveedores flexibles.

Si se atiene a recomendaciones como el principio DRY, el desacoplamiento y el uso de metadatos, no tendrá que tomar muchas decisiones críticas e irreversibles.

3. Balas trazadoras

Las balas trazadoras le ayudarán a encontrar rápidamente su objetivo en circunstancias reales y le proporcionarán información a usted y a sus usuarios. Un código trazador puede ser una única característica implementada de extremo a extremo en todas las capas. Un código trazador llega rápido al objetivo y proporciona una retroalimentación inmediata. Y desde un punto de vista práctico, son una solución relativamente barata. Para conseguir el mismo efecto en el código, buscamos algo que nos lleve de un requisito a algún aspecto del sistema final de forma rápida, visible y repetida.

Ventajas

• Dispone de una plataforma de integración.
• Tendrá una mejor sensación del progreso.
• Los usuarios pueden ver algo que funciona desde el principio.
• Ayude a construir una estructura en la que trabajar.

Código trazador frente a prototipos

Podría pensar que el concepto de código trazador no es más que la creación de prototipos; hay una diferencia. Al crear prototipos, su objetivo es explorar aspectos concretos del sistema final. Con un prototipo real, desechará todo lo que haya trucado al probar el concepto y lo recodificará adecuadamente utilizando las lecciones aprendidas. El enfoque del código trazador aborda un problema diferente. Necesita saber cómo funciona la aplicación en su conjunto. Quiere mostrar a sus usuarios cómo funcionarán las interacciones en la práctica y dar a sus desarrolladores un esqueleto arquitectónico en el que colgar el código.

Cita favorita del capítulo: «Nada es más peligroso que una idea si es la única que tienes».

Capítulo 3: Las herramientas básicas

1. El poder del texto sin formato

Como programador pragmático, su material de base es el conocimiento. Usted reúne los requisitos como conocimiento y luego los expresa en sus diseños, implementaciones, pruebas y documentos. El mejor formato para almacenar conocimientos es el texto sin formato.

¿Qué es el texto sin formato?

El texto sin formato comprende caracteres imprimibles para que la gente pueda leerlo y entenderlo directamente. Con el texto sin formato, usted se da la posibilidad de manipular el conocimiento tanto manual como programáticamente utilizando prácticamente todas las herramientas a su disposición.

2. Juegos de conchas

Todo carpintero necesita un banco de trabajo adecuado, sólido y fiable en algún lugar para sujetar las piezas a una altura conveniente mientras trabaja en ellas.

Como programador que manipula archivos de texto, su banco de trabajo es el intérprete de comandos. A través del prompt del shell, puede invocar todo su repertorio de herramientas. El prompt del shell le permitirá lanzar aplicaciones, depuradores, navegadores, editores y utilidades. Podrá buscar archivos, consultar el estado del sistema y filtrar la salida. Programando el intérprete de comandos, podrá construir macrocomandos multiplexados para actividades que realice con frecuencia.

Utilidades Shell y sistemas Windows

Aunque los shells de comandos que proporcionan los sistemas Windows están mejorando gradualmente, las utilidades de línea de comandos de Windows siguen siendo inferiores a sus homólogas de Linux/Unix. Sin embargo, no todo está perdido.

Cygnus Solutions dispone de un paquete llamado Cygwin. Además de proporcionar una capa de compatibilidad Linux/Unix para Windows, Cygwin viene con una colección de más de 120 utilidades Unix, incluyendo las favoritas como 1s, grep y find. Las utilidades y bibliotecas pueden descargarse y utilizarse gratuitamente, pero lea su licencia. La distribución Cygwin viene con el shell Bash.

3. Edición de potencia

Las herramientas son una extensión de su mano. Esto se aplica a los editores más que a cualquier otra herramienta de software. Elija un editor que le permita manipular el texto con el menor esfuerzo posible, porque el texto es la materia prima principal de la programación.

Un editor

Es mejor conocer muy bien un editor y utilizarlo para todas las tareas de edición: código, documentación, notas, administración del sistema, etc. Con múltiples editores, se enfrenta a un posible caos de confusión moderno. Puede que tenga que utilizar el editor integrado en el IDE de cada idioma para codificar, un producto ofimático todo en uno para la documentación y tal vez un editor integrado diferente para enviar correos electrónicos. Incluso las pulsaciones de teclas que utiliza para editar líneas de comandos en el shell pueden diferir. Es difícil ser competente en cualquiera de estos entornos si tiene un conjunto diferente de convenciones y comandos de edición en cada uno de ellos.

Por lo tanto, elija un único editor, conózcalo en profundidad y utilícelo para todas las tareas de edición. Utilice un único editor o conjunto de combinaciones de teclas para todas las actividades de edición de texto. No tendrá que pararse a pensar para manipular el texto: las pulsaciones de teclas necesarias serán un reflejo. El editor será una extensión de su mano, las teclas cantarán mientras se abren paso a través del texto y el pensamiento. Asegúrese de que el editor que elija esté disponible en todas las plataformas que utilice. Emacs, vi, CRiSP, Brief y otros están disponibles en varias plataformas, a menudo en versiones GUI y no GUI (pantalla de texto).

Características del editor:

• Configurable
• Extensible
• Programable

Cita favorita del capítulo: «Las herramientas amplifican su talento. Cuanto mejores sean sus herramientas y mejor sepa utilizarlas, más productivo podrá ser».

Capítulo 4 La paranoia pragmática

1. Diseño por contrato

El concepto de diseño por contrato es una técnica sencilla pero poderosa que se centra en documentar y acordar los derechos y responsabilidades de los módulos de software para garantizar la corrección del programa. Un programa correcto no hace ni más ni menos de lo que afirma hacer. Documentar y verificar esa afirmación es el corazón del diseño por contrato. Cada función y método de un sistema de software hace algo. Antes de comenzar, la rutina puede tener algunas expectativas sobre el estado del mundo. Las expectativas y afirmaciones incluyen;

• Precondiciones: ¿Qué debe ser válido para que se llame a la rutina?
• Invariantes de clase: Una clase garantiza que esta condición sea siempre real desde la perspectiva de quien llama.
• Postcondiciones: El hecho de que la rutina tenga una postcondición implica que concluirá: los bucles infinitos no están permitidos.

Aplicación del diseño por contrato

La principal ventaja de utilizar DBC es que obliga a poner en primer plano la cuestión de los requisitos y las garantías. Enumerar simplemente en el momento del diseño cuál es el rango del dominio de entrada, las condiciones de contorno y lo que la rutina promete entregar o lo que no promete entregar es un paso de gigante para escribir un software mejor. Cuando no se enuncian estas cosas, entonces se está programando por casualidad y aquí es donde empiezan, acaban y fracasan muchos proyectos. En los lenguajes que no admiten DBC en el código, esto es lo más lejos que se puede llegar, lo que no está tan mal. Al fin y al cabo, DBC es una técnica de diseño.

2. Los programas muertos no mienten

Es fácil caer en la mentalidad de «eso no puede ocurrir». La mayoría de ustedes ha escrito código que no comprobaba que un archivo se cerraba con éxito o que una sentencia trace se escribía como usted esperaba. En igualdad de condiciones, es probable que no lo necesitara, el código en cuestión no fallaría en condiciones normales. Pero usted está codificando a la defensiva. Está buscando punteros deshonestos en otras partes de su programa y destrozando la pila. Está comprobando que las versiones cargadas de las bibliotecas compartidas son correctas.

Todos los errores le proporcionan información. Podría convencerse de que el error no puede producirse y optar por ignorarlo. En cambio, un programador pragmático se dice a sí mismo que algo muy, muy malo ha ocurrido si hay un error.

Chocar, no tirar

Una de las ventajas de detectar los problemas lo antes posible es que puede chocar antes.

Y muchas veces, estrellar su programa es lo mejor que puede hacer. La alternativa puede ser seguir escribiendo datos corruptos en alguna robusta base de datos o mandar a la lavadora a su vigésimo centrifugado consecutivo.

3. Programación asertiva

El recuento no puede ser negativo, la impresión no puede fallar, el registro no puede fallar o esto no puede ocurrir nunca. No practique este tipo de engaños, especialmente cuando codifique. Si no puede ocurrir, aplique aserciones para asegurarse de que no ocurrirá.

Siempre que piense que «eso nunca podría ocurrir», añada código para comprobarlo. La forma más sencilla de hacerlo es mediante el uso de aserciones. En la mayoría de las implementaciones de C y C++, encontrará algún tipo de macro assert o assert que comprueba una condición booleana. Estas macros pueden tener un valor incalculable. Las aserciones también ayudan a comprobar el funcionamiento de un algoritmo. Digamos que ha escrito un algoritmo inteligente; las aserciones comprobarán que funciona.

No aplique aserciones en lugar de la gestión de errores real. Las aserciones comprueban cosas que nunca deberían ocurrir y asegúrese de que el método de aserción que utiliza no realiza ningún efecto secundario que pueda crear nuevos errores.

Deje las afirmaciones en

La gente que escribe compiladores y entornos de lenguaje tiene una interpretación errónea de las aserciones muy extendida. Dice así: «Las aserciones añaden cierta sobrecarga al código. Como comprueban cosas que nunca deberían ocurrir, sólo se activarán por un error en el código. Una vez que el código haya sido probado y enviado, desactive las aserciones para que el código se ejecute más rápido».

Cita favorita del capítulo: «Las aserciones añaden cierta sobrecarga al código. Dado que comprueban cosas que nunca deberían ocurrir, sólo se activarán por un error en el código. Una vez que el código ha sido probado y enviado, ya no son necesarias y deberían desactivarse para que el código se ejecute más rápido.»

Capítulo 5: Doblar o romper

1. La disociación y la ley de Deméter

Organice su código en módulos y controle la interacción entre ellos. Si un módulo se ve comprometido y tiene que ser sustituido, los demás módulos deben seguir adelante.

Minimizar el acoplamiento

No hay nada malo en tener módulos que se conozcan entre sí. Sin embargo, debe tener cuidado con cuántos otros módulos interactúa y, lo que es más importante, cómo llegó a interactuar con ellos. Cuando pide a un objeto un servicio específico, quiere que el servicio se ejecute en su nombre. No quiere que el objeto le proporcione una entidad tercera con la que tenga que tratar para obtener el servicio requerido.

La ley de Deméter

La ley de Deméter para las funciones establece que cualquier método de un objeto sólo debe llamar a procesos que pertenezcan a él mismo, a cualquier parámetro pasado al método, a cualquier objeto que haya creado y a cualquier objeto compuesto que tenga directamente. La ley de Deméter tiene como objetivo minimizar el acoplamiento entre módulos en un programa determinado; evita que se llegue a un objeto para acceder a los métodos de un tercer objeto. Escribir código «tímido» hace honor a la Ley de Deméter y logra su objetivo de minimizar el acoplamiento entre módulos.

2. Metaprogramación

Los detalles estropean significativamente su código perfecto si cambian con frecuencia. Cada vez que tenga que entrar y cambiar el código para adaptarlo a algún cambio en la lógica empresarial, en la legislación o en los gustos del momento de la dirección, corre el riesgo de romper el sistema introduciendo un nuevo fallo.

¡Basta ya de detalles! Sáquelos del código. De paso, haga que su código sea altamente configurable y «suave». Es decir, fácilmente adaptable a los cambios.

Configuración dinámica

Configure, no integre. Debe hacer que sus sistemas sean altamente configurables. No sólo los colores de la pantalla o el texto de los avisos, sino elementos profundamente arraigados como la elección de algoritmos, productos de bases de datos, tecnología de middleware y estilo de la interfaz de usuario deben aplicarse como opciones de configuración y no mediante integración o ingeniería.

Cuándo configurar

Represente sus metadatos de configuración en texto sin formato; le facilitará mucho la vida. Pero, ¿cuándo debe un programa leer esta configuración? Muchos programas analizan este tipo de cosas sólo al iniciarse, lo cual es desafortunado porque se verá obligado a reiniciar la aplicación cuando necesite cambiar la configuración. Un enfoque más flexible es escribir programas que recarguen su configuración mientras se ejecutan. Aunque esta flexibilidad tiene un coste, es más compleja de implementar.

Así que considere cómo utilizarán los usuarios su aplicación: si se trata de un proceso de servidor de larga duración, querrá proporcionar alguna forma de releer y aplicar metadatos mientras el programa se ejecuta. Para una pequeña aplicación GUI cliente que se reinicia rápidamente, puede que no lo necesite.

3. Acoplamiento temporal

Aquí, el escritor habla del tiempo como un elemento de diseño del propio software. Hay dos aspectos del tiempo que son importantes para usted: la concurrencia (cosas que suceden simultáneamente) y el ordenamiento (las posiciones relativas de las cosas en el tiempo). En el acoplamiento temporal, la concurrencia se llama siempre antes que la ordenación; sólo se puede ejecutar un informe a la vez; después, hay que esperar a que se redibuje la pantalla antes de recibir el clic del botón.

Cita favorita del capítulo: «Ningún genio puede superar la preocupación por el detalle».

Capítulo 6: Mientras codifica

1. Programar por casualidad

Hay cientos de trampas esperando para atraparle cada día como desarrollador. Recuerde que debe tener cuidado con sacar conclusiones falsas. Evite programar por casualidad, confiando en la suerte y en los éxitos accidentales, en favor de programar deliberadamente. Cuando programe por casualidad y su código falle, no sabrá por qué falló porque no sabía por qué funcionaba en primer lugar con las escasas pruebas que realizó.

Accidentes de aplicación

Los accidentes de implementación son cosas que ocurren simplemente porque así está escrito el código. Usted acaba confiando en errores no documentados o en condiciones límite. La condición límite en la que confía puede ser simplemente un accidente. En otras circunstancias (una resolución de pantalla diferente, quizás), podría comportarse de forma diferente.

El comportamiento no documentado puede cambiar con la próxima versión de la biblioteca.

Cómo programar deliberadamente

• No codifique con los ojos vendados.
• Confíe sólo en cosas fiables. No dependa de accidentes o suposiciones.
• Documente sus suposiciones.

2. Velocidad del algoritmo

Como programador pragmático, usted calcula los recursos de los algoritmos, como el tiempo, el procesador y la memoria. La mayoría de los algoritmos no triviales manejan algún tipo de entrada variable; el tamaño de esta entrada repercutirá en el algoritmo. Cuanto mayor sea la información, mayor será el tiempo de ejecución o más memoria se utilizará.

Descubrirá que inconscientemente comprueba el tiempo de ejecución y los requisitos de memoria cada vez que escriba algo que contenga bucles o llamadas recursivas. Este proceso es una confirmación rápida de que sus acciones son sensatas dadas las circunstancias. Por lo tanto, usted se encuentra ejecutando un análisis más detallado. Es entonces cuando la notación O() resulta útil. La notación O() es una forma matemática de tratar las aproximaciones.

3. Refactorización

El código necesita evolucionar, no es estático. A medida que un programa se desarrolla, se hace necesario replantearse decisiones anteriores y reelaborar partes del código. Reescribir, reestructurar y rediseñar un cuerpo de código existente, alterando su estructura interna sin cambiar su comportamiento externo se conoce como refactorización.

¿Cuándo debe refactorizar?

Si se encuentra con un escollo porque el código ya no encaja o nota dos cosas que debería fusionar, no dude en cambiarlo. He aquí varias cosas que pueden hacer que el código cumpla los requisitos para ser refactorizado:

Duplicación. Ha descubierto una violación del principio DRY (Don’t Repeat Yourself).

Diseño no ortogonal. Ha descubierto algún código o procedimiento que podría hacerse más ortogonal (Ortogonalidad).

Conocimientos obsoletos. Las cosas cambian, los requisitos se desvían y su comprensión del problema aumenta. El código tiene que seguir el ritmo.

Rendimiento. Es necesario trasladar funciones de un área del sistema a otra para mejorar el rendimiento.

4. Código fácil de probar

En los chips y sistemas más complejos, los desarrolladores de hardware incluyen características como un completo autodiagnóstico incorporado (BIST) que ejecuta internamente diagnósticos de nivel básico y un mecanismo de acceso a pruebas (TAM) que proporciona un arnés de pruebas que permite al entorno externo proporcionar estímulos y recoger respuestas del chip. Puede hacer lo mismo en el software, incorporar la comprobabilidad en el software desde el principio y probar cada pieza en detalle antes de intentar conectarlas entre sí.

Pruebas unitarias

Las pruebas a nivel de chip para el hardware son equivalentes a las pruebas unitarias en el software. Las pruebas se realizan en cada módulo de forma aislada para verificar su comportamiento. Podrá comprender mejor cómo reaccionará un módulo en el gran mundo una vez que lo haya probado a fondo en condiciones controladas.

Una prueba unitaria de software es un código que ejercita un módulo. Normalmente, la prueba unitaria creará un entorno artificial y luego evocará rutinas en el módulo que se está probando. A continuación, la prueba unitaria comprueba los resultados devueltos, ya sea frente a valores conocidos o frente a los resultados de las ejecuciones anteriores de la misma prueba.

Más adelante, cuando reúna sus «circuitos integrados de software» en un sistema completo, tendrá la seguridad de que las piezas individuales funcionan como se espera. Entonces podrá utilizar las mismas instalaciones de pruebas unitarias para probar el sistema en su conjunto.

Cita favorita del capítulo: «Todo el software que escriba será probado -si no por usted y su equipo, sí por los usuarios finales-, así que más vale que planee probarlo a fondo».

Capítulo siete: Antes del proyecto

1. El pozo de los requisitos

La recopilación de requisitos es una fase temprana del proyecto. La recopilación implica que los requisitos ya están ahí, sólo tiene que encontrarlos. Póngalos en su cesta y siga su camino. Aunque no funciona así, los requisitos rara vez salen a la superficie. Están enterrados profundamente bajo capas de suposiciones, ideas equivocadas y política.

En busca de necesidades

¿Cómo identificará una auténtica necesidad cuando escarbe en la suciedad circundante? La respuesta es a la vez compleja y directa. La respuesta directa es una declaración de algo que debe cumplirse. Por otro lado, muy pocos requisitos son claros, lo que hace que el análisis de requisitos sea complejo.

En caso de que el requisito se enuncie como «Sólo el personal puede ver un registro de empleado», entonces acabará codificando una prueba directa cada vez que la aplicación acceda a estos archivos. Sin embargo, si el enunciado es «Sólo los usuarios autorizados pueden acceder a un expediente de empleado», es probable que el desarrollador diseñe e implemente algún tipo de sistema de control de acceso. Cuando cambie la política, sólo habrá que actualizar los metadatos de ese sistema. Recopilar los requisitos de este modo le conducirá a un sistema bien diseñado para soportar metadatos.

2. Resuelva rompecabezas imposibles

Piense en los rompecabezas del mundo real que aparecen como regalos de Navidad o en ventas de garaje. Tiene que quitar la anilla o encajar las piezas en forma de T en la caja. Saca el anillo y descubre rápidamente que las soluciones aparentes no resuelven el rompecabezas. La respuesta está en otra parte. El secreto para resolver el rompecabezas consiste en identificar las verdaderas limitaciones y encontrar en ellas una solución. Algunas limitaciones son absolutas, otras son meras nociones preconcebidas. Las limitaciones fundamentales deben respetarse, por desagradables o estúpidas que parezcan. Por otro lado, algunas limitaciones aparentes pueden no ser exactas.

No piense fuera de la caja – Encuentre la caja

Cuando se enfrente a un problema insoluble, enumere todas las vías posibles que tiene ante usted.

No descarte nada, por inutilizable o estúpido que parezca. Repase la lista y explique por qué no puede tomar un camino concreto. ¿Puede demostrarlo?

3. No hasta que esté preparado

Cuando sienta una duda persistente o desgana al enfrentarse a una tarea, préstele atención. Puede que no sea capaz de averiguar qué es exactamente lo que falla. Dele tiempo y es probable que sus dudas cristalicen en algo más sólido, algo que pueda abordar. El desarrollo de software aún no es una ciencia. Deje que sus instintos contribuyan a su rendimiento.

¿Buen juicio o dilación?

Comenzar un nuevo proyecto o incluso un nuevo módulo en un proyecto existente puede ser una experiencia dolorosa. Muchos preferirían aplazar el compromiso inicial de empezar. Entonces, ¿cómo puede saber cuándo está simplemente procrastinando en lugar de esperar responsablemente a que todas las piezas encajen en su sitio?

En estas circunstancias, una técnica que le funcionará es la creación de prototipos. Seleccione un área que le parezca difícil y empiece a producir alguna prueba de concepto. Poco después, pensará que está perdiendo el tiempo. Este aburrimiento es probablemente un buen indicio de que su reticencia inicial era sólo un deseo de aplazar el compromiso de empezar. Abandone el prototipo y dedíquese al desarrollo real.

Cita favorita del capítulo: «La perfección se alcanza, no cuando no queda nada por añadir, sino cuando no queda nada por quitar….».

Capítulo ocho: Proyectos pragmáticos

1. Pruebas implacables

Pruebe pronto, pruebe a menudo y pruebe automáticamente. Debe empezar a realizar pruebas en cuanto tenga el código. Desarrolle planes de pruebas elaborados para sus proyectos. Los equipos que utilizan pruebas automatizadas tienen muchas más posibilidades de éxito. Las pruebas que se ejecutan con cada compilación son mucho más eficaces que los planes de pruebas en una estantería. Recuerde que cuanto antes encuentre un fallo, más barato le resultará remediarlo. «Codifique un poco, pruebe un poco».

Para que su proyecto sea satisfactorio, debe tener más código de prueba que de producción. El tiempo que se pierde al producir este código de prueba merece la pena y resulta más barato a largo plazo. También tiene la posibilidad de crear un producto con casi cero defectos.

2. Grandes expectativas

El éxito del proyecto de su equipo se mide por cómo cumple las expectativas de sus usuarios. Si su proyecto queda por debajo de sus expectativas, entonces se considera un fracaso, independientemente de lo bueno que sea el producto final en términos absolutos.

La milla extra

Supere suavemente las expectativas de sus usuarios. No asuste a sus usuarios; en su lugar, sorpréndalos. Deles un poco más de lo que esperaban. El esfuerzo adicional necesario para añadir al sistema alguna característica orientada al usuario se amortizará una y otra vez en buena voluntad.

3. Orgullo y prejuicio

Como programador pragmático, no debe huir de la responsabilidad. Al contrario, alégrese cuando se enfrente a retos y dé a conocer su pericia laboral. Si es responsable de un diseño o de un fragmento de código, hará un trabajo del que se sentirá orgulloso.

Firme su trabajo

Siéntase orgulloso de su trabajo. «Usted escribió esto y debería respaldar su trabajo». Su firma debería llegar a ser reconocida como un indicador de calidad. La gente debería ver su nombre en un trozo de código y esperar que sea sólido, esté bien escrito, probado y documentado: un trabajo profesional realizado por un verdadero profesional.

Cita favorita del capítulo: «La civilización avanza ampliando el número de operaciones importantes que podemos realizar sin pensar».

¿CÓMO PUEDE AYUDAR ESTE LIBRO A LOS DESARROLLADORES DE SOFTWARE?

«El programador pragmático» de Andrew Hunt y David Thomas es un libro clásico de desarrollo de software que ofrece consejos prácticos y técnicas para mejorar la forma de trabajar de los desarrolladores. Abarca temas como la depuración, las pruebas, la automatización y la gestión de proyectos, así como la importancia de la comunicación y el aprendizaje continuo. Siguiendo las orientaciones del libro, los desarrolladores pueden mejorar sus habilidades de codificación, aumentar la productividad, trabajar de forma más eficiente, convertirse en miembros más eficaces del equipo y ofrecer mejores productos de software.