h1

Código Pragmático

04/22/2008

Wizdoc [Icon By Buuf]Wizbook [Icon By Buuf]

 Tips & Tricks / Libros

…Desafortunadamente, la metáfora más socorrida para el desarrollo de software es la construcción de edificios… implicando los siguientes pasos:

  1. Un arquitecto dibuja unos planos.
  2. Los contratistas plantan los cimientos, construyen la superestructura, cablean e instalan la plomería y aplican los toques finales.
  3. Los inquilinos se mudan y viven felices por siempre, llamando a mantenimiento para corregir cualquier problema.

Bueno, el software no funciona de esta manera. En vez de la construcción, el software es más parecido a la jardinería – siendo más orgánico que concreto. Puedes plantar muchas cosas de acuerdo a un plan y condiciones iniciales. Algunas crecen y otras están destinadas a ser composta. Puedes cambiar los retoños parecidos para tomar ventaja de las condiciones de luz y sombra, viento y lluvia. Las plantas demasiado crecidas son cortadas o podadas, y los colores que no combinan pueden moverse a locaciones estéticamente más agradables. Eliminas hierbas y fertilizas las plantas que necesitan un poco más de ayuda. Constantemente monitoreas la salud del jardín, y realizas ajustes (a la tierra, las plantas, el diseño) conforme se requiera. En pocas palabras, creas tu jardín teniendo siempre en mente el concepto de Refactoring.

The Pragmatic Programmer: From Journeyman to Master; Andrew Hunt, David Thomas © 1999

Continuando con la filosofía pragmática mostrada la semana pasada, deposito aquí el condensado – con algo de mi cosecha – de algunos Tips & Tricks encontrados en The Pragmatic Programmer: From Journeyman to Master que tienen que ver con nuestra área de conocimiento; sin embargo lo considero algo muy apropiado incluso para aquellas ingenierías que no son necesariamente de software:

  • Los peligros de la duplicación. La mejor forma de convertir un sistema en un monstruo sin principio ni fin y hacer perder el sueño a los pobres desafortunados que les toque dar mantenimiento a un sistema es la repetición de código. Por ello NO debemos repetir piezas de información:
    public class Line {
      public Point start;
      public Point end;
      public double length;
    }

    ¿Qué tiene de malo este código? Que la longitud de la línea debe ser modificada cada que cambiamos alguno de los puntos de la misma. Por ello, si se nos olvida actualizar dicho valor incurriremos en un error de lógica bastante difícil de encontrar. Es mucho más fácil eliminar el campo o si forzosamente debemos tenerlo, podemos indicar al objeto que actualice el valor o que lo recalcule cada que se lo pidamos:

    public class Line {
      private Point start;
      public Point end;
      public double length() {
        return Math.sqrt( Math.pow( ( start.getX() – end.getX() ),2 )
        + Math.pow( ( start.getY() – end.getY() ),2) );
      }

    }

  • Baja dependencia o Acoplamiento. En pocas palabras, al modificar una pieza de código no deberíamos modificar otras, pues los sistemas que contienen un alto grado de acoplamiento son mucho más complejos de mantener y controlar. Cuando los componentes de un sistema son altamente interdependientes, no existe algo así como un fix local. Esta es la gran tragedia de los lenguajes como Java o C++: mal programados (utilizando un paradigma procedural) podemos perder todos los beneficios de la programación orientada a objetos.
  • Genera tu programación, diseño y arquitecturas de forma que sean flexibles. ¿Cuántas veces no nos ha tocado una conversación de este tipo?
    Programador: ¡Pero dijiste que usaríamos SQL Server! Llevamos el 85% de la construcción del proyecto ¡no podemos cambiar ahora!
    Project Manager: Lo siento, pero el cliente decidió estandarizar sus bases de datos a Oracle para todos sus proyectos. No está en mis manos y tendremos que recodificar. Tenemos que venir a trabajar los fines de semana hasta nuevo aviso.

    Por ello siempre hay que tener en cuenta el cambio en nuestro trabajo y cómo nos va a impactar. El ejemplo del libro es espectacular:

    Tiempo para un poco de mecánica cuántica con el Gato de Schrödinger:

    Supongamos que tienes un gato en una caja cerrada, junto a una partícula radioactiva. La partícula tiene exactamente una probabilidad de 50% de fisionarse en dos. Si la partícula fisiona, el gato se muere. Si no lo hace, el gato estará bien. Así que, ¿el gato esta vivo o muerto?

    De acuerdo a Schrödinger, la respuesta correcta es ambos. Cada vez que una reacción sub-atómica ocurre y pueden existir dos alternativas, el universo se clona. En uno, el evento ocurrió y en el otro no. El gato está vivo en un universo, muerto en otro. Sólo cuando abres la caja te das cuenta en qué universo te encuentras.

    No es de extrañar que la codificación a futuro sea muy difícil.

    Sin embargo, piensa en la evolución del código en el mismo sentido que una caja llena de gatos de Schrödinger: cada decisión resulta en una nueva versión del futuro. ¿Cuántos posibles futuros puede soportar tu código? ¿Cuáles son más probables? ¿Qué tan difícil será soportar esos cambios cuando se den?

    ¿Te atreves a abrir la caja?

    The Pragmatic Programmer: From Journeyman to Master; Andrew Hunt, David Thomas © 1999

  • Implementa pruebas de concepto y prototipos. Básicamente existen dos formas de crear un sistema:
    • Trabaja en un modelo de cascada de forma que realices un levantamiento exhaustivo del sistema a construir y reza por que no hayan cambios en las especificaciones o en la lógica de negocio de tu cliente. Claro que por presiones de todos los stakeholders, querrán ver algún avance, lo que te obligará a construir algo a lo que le irás endosando parches y piezas de código hasta que se convierta en una Gran Bola de Lodo.
    • Genera prototipos: empieza con algo pequeño que sea visible al cliente y ve agregando funcionalidad poco a poco. Simples pantallazos pueden ser un buen comienzo. Involucra al cliente y recibe retroalimentación con respecto a tus prototipos. En menos de lo que crees tendrás una aplicación funcionando y lo más importante: que el cliente lo considere como algo revisado y aprobado.

    Adicionalmente, al generar prototipos y pruebas de concepto te puedes ir dando cuenta que hay algunas tareas que no pueden realizarse tan fácilmente. ¿Que tu cliente pide una integración con .NET en 1 día? Con una prueba de concepto (Proof of Concept – POC) puedes demostrarle que no es algo de enchílame otra gorda.

  • Un punto relacionado al anterior: cuando estés generando prototipos, considéralos como código desechable; aunque puedas hacer pequeños batidillos para sacar el prototipo rápidamente, tienes al menos dos opciones:
    • El prototipo es tu Proyecto Base: Es necesario hacer limpieza y refactoring para que sea efectivo, eficiente y robusto. No puedes dejarlo parchado o con código en mal estado porque acabará pudriendo todo lo demás.
    • El prototipo es desechable: Notifica a todos los involucrados que el prototipo es sólo eso y que no se seguirá trabajando sobre el mismo. Esto para que el usuario no se quede con la idea equivocada de que iterando sobre ese código ahorran tiempo.
  • Estimaciones. Aprende a estimar; no basta con decir este programita me lo echo en tantas horas. Hay que saber estimar y poder presentar y defender nuestros estimados. Mi recomendación: Software Estimation: Demystifying the Black Art de Steve McConnell. Como comentan en dicho libro, cada que necesites hacer una estimación trata de seguir este orden: cuenta, calcula, juzga.
  • Construye tu software de manera que siempre sea fácil de probar. Utiliza JUnit, MockObjects y demás frameworks para apoyarte en este tipo de codificación. Genera un daily build para comprobar que al menos todo compila.
  • No seas un esclavo de las metodologías formales. Hay algunas cosas que son más fáciles de hacer que de describir. Por ello la popularidad de XP o SCRUM por encima de RUP.

Con esto termino mi resumen del libro. Adicionalmente nos dan otros tips y herramientas con los que podemos evitar batidillos y proyectos fallidos: desde saber qué es la administración de requerimientos (llamado el Pozo de los Requerimientos), saber cómo documentar nuestro código o como trabajar en base al lema codifica-integra-prueba. Pero para ello, recomiendo que bajen el e-book de alguno de los múltiples sitios que ofrecen dichas descargas o mejor aún: cómprense el original bonito y empastado. Les aseguro que es una excelente inversión.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: