Test de Joel: 11 pasos para mejorar tus aplicaciones web

2 de diciembre 2009
Tags: , , ,

El Test de Joel fué enunciado hace una década por Joel Spolsky y permite conocer si estamos desarrollando de una forma adecuada buenas aplicaciones, contestando si o no a 12 preguntas. Según Joel, si se respondía positivamente a las 12 preguntas obteniendo por tanto una puntuación de 12, entonces se podría asegurar que estábamos desarrollando un código excepcional, en caso de obtener 11 puntos se trataría de una puntuación tolerable pero 10 o menos pondría en evidencia nuestras carencias y la baja calidad de nuestro trabajo.

Cuando Joel ideó éste test, el desarrollo web aún estaba en sus primeras fases y el test se aplicaba fundamentalmente al desarrollo tradicional de software de escritorio. Tras leer el artículo original de Joel y algunas adaptaciones al desarrollo web del test, me atrevo a realizar mi propia adaptación que en realidad se asemeja bastante a la propuesta por Brandon Savage.

Mi Test de Joel modificado para el desarrollo Web sería:

  1. ¿Usas control de versiones?
  2. ¿Puedes preparar una versión distribuible de la aplicación en un solo paso?
  3. ¿Estás usando integración continua?
  4. ¿Tienes un sistema para el bug tracking?
  5. ¿Pones solución a los bugs antes de seguir escribiéndo nuevo código?
  6. ¿Mantienes continuamente actualizado tu calendario de desarrollo?
  7. ¿Tienes una hoja de especificaciones para la aplicación que estas construyendo?
  8. ¿Te sientes cómodo en tu lugar de trabajo?
  9. ¿Usas las mejores herramientas aunque sean caras?
  10. ¿Tienes beta-testers?
  11. ¿Es tu aplicación usable?

Simplemente contestando si o no a éstas 12 preguntas podemos averiguar si nuestro proceso de desarrollo es el adecuado o no para poder producir aplicaciones web de calidad. Y todo ésto en menos de 5 minutos al contrario de otras complicadas y laboriosas técnicas de medida de calidad del software cómo por ejemplo las desarrolladas por el prestigioso Carnegie Mellon.

1. ¿Usas control de versiones?

Desde mi punto de vista fundamental. En cualquier flujo de trabajo, sea cual sea la metodología empleada, debería de contemplarse un sistema de control de versiones. Yo uso Subversion, pero puedes usar también Git que cada vez gana mas adeptos. Además tienes el servicio github.com que es una maravilla.

2. ¿Puedes preparar una versión distribuible de la aplicación en un solo paso?

La estructura de la aplicación web debe permitir que seas capaz de trasportar la aplicación a otro servidor Web en un solo paso. O al menos en 3 micropasos: copiar todos los archivos, copiar la base de datos y editar el único archivo de configuración con los datos del nuevo servidor.

3. ¿Estás usando integración continua?

En la versión original del test, éste punto trata sobre poder construir una versión ejecutable diaria de la aplicación. ésto no tiene mucho sentido en el desarrollo de webs, por lo que es conveniente poder realizar una integración continua.

Con integración continua me refiero a realizar Pruebas de Unidad, realizar Refactoring y mantener una buena documentación.

Para las pruebas de Unidad podemos usar PHPUnit o si como yo usas el framework CodeIgniter, tienes a tu disposición la clase Unit Testing incluida en el propio framework.

El Refactoring es una tecnica de Ingeniería del software que consiste en reescribir nuestro código para que sea mas legible pero sin alterar su funcionamiento. Para ello podríamos seguir algunas guías de estilo para tener un código que pueda entenderlo rápidamente cualquier programador ajeno a nuestro proyecto.

Para el tema de la documentación casi siempre he usado Doxygen, pero también está muy extendido phpDocumentor. Una buena documentación es imprescindible para poder escalar nuestra aplicación en un futuro y poder extenderla con mas funcionalidades.

4. ¿Tienes un sistema para el bug tracking?

Se necesita llevar un control de todos los bugs que se van encontrando en la aplicación. Se debe anotar 4 cosas:

  • Pasos que se han seguido para que de lugar el error.
  • El comportamiento que se debería esperar en lugar del error.
  • El comportamiento qeu se ha obtenido (el error en sí)
  • A quien se le asigna el estudio de éste bug (en caso de haber mas componentes en el desarrollo)
  • Si ha sido resuelto el bug o no.

Para llevar un control de ésta información nos bastaría con un simple documento de 4 columnas para anotar los puntos anteriores aunque lo reocmendable es usar sistemas pensados para ello. Mi preferido: TRAC, aunque hay otros como Mantis

5. ¿Pones solución a los bugs antes de seguir escribiéndo nuevo código?

Si tienes una pila de bugs por corregir, no tiene sentido que sigas escribiéndo mas código, párate a resolver antes los problemas encontrados.

6. ¿Mantienes continuamente actualizado tu calendario de desarrollo?

Estimar las horas de desarrollo de una aplicación es terriblemente difícil, aun dividiendo la estimación en pequeñas partes. Aun así, es fundamental tener una hoja de ruta con fechas que iremos actualizando casi a diario para poder ajustarlo a la realidad.

7. ¿Tienes una hoja de especificaciones para la aplicación que estas construyendo?

Es necesario tener una lista de requerimientos que busca el cliente que tenga la aplicación, complementándose con los requerimientos que tu como desarrollador piensas que tiene que tener. Nos servirá para poder confeccionar el calendario del que hemos hablado en el punto anterior. Si no tienes una hoja de especificaciones, el desarrollo se puede convertir en un viaje sin rumbo en el que la pérdida de tiempo está asegurada. Es muy importante tener varias entrevistas con el cliente para acordar de forma clara Qué debe hacer y cómo lo debe hacer la aplicación.

8. ¿Te sientes cómodo en tu lugar de trabajo?

Para programar se necesita un lugar calmado. Nada de télefonos alrededor. Nada de distracciones de ningún tipo. Cuando estás programando tienes en tu cabeza mil ideas que pueden derrumbarse como un castillo de naipes si tan solo vienen a preguntarte algo en el momento equivocado. Si el trabajo va a ser en equipo habrá que estabelcer algunas normas para que ésto no suceda y todos los integrantes sean lo mas productivos posibles.

Cuando estás programando, estás programando, no puedes estar realizando otras tareas a la vez, asi de simple. Si lo haces, tu productividad se verá tan sumamente perjudicada que no podrás avanzar nada. Es algo que en muchas empresas deberían comprender.

Cubículos, oficinas, tu propio sitio de trabajo en casa, en mi opinión da igual mientras te sientas cómodo.

9. ¿Usas las mejores herramientas aunque sean caras?

Aunque tenemos la suerte de que hoy por hoy existe muchas herramientas de software libre y que ademas en la mayoría de los casos son gratuitas, en algunas ocasiones nos encontramos que la mejor herramienta para alguna determinada tarea es de pago. Si verdaderamente queremos sacar el mejor provecho de nuestro esfuerzo, será mejor que nos hagamos con esa herramienta. Si trabajamos para alguna empresa, ésta nos debería proveer de libros técnicos especializados, buenos equipos y buen software. Sin duda, es una inversión que les será altamente rentable.

10. ¿Tienes beta-testers?

Aunque le apliquemos pruebas de unidad, etc, como dijimos en el punto 3, es altamente recomendable ayudarnos de algunos beta testers que nos puedan dar una visión mas humana de las posibles carencias de nuestra aplicación. Incluso si el conocimiento a nivel técnico de éstos beta-testers no es muy alto, pueden darnos una idea del grado de usabilidad que tiene nuestra aplicación.

11. ¿Es tu aplicación usable?

La facilidad de uso de nuestro aplicación puede ser el punto que decida si será un éxito o no. Diseños mas simples y menos recargados, conjuntamente con interfaces intuitivos y fáciles de manejar harán de nuestra aplicación una apuesta segura. Cuidaremos especialmente, la paleta de colores elegida, la tipografía y la disposición del contenido.

12. Los nuevos candidatos para tu proyecto, ¿han demostrado cierto nivel técnico en programación?

Éste punto solo es aplicable si hablamos de grupos de desarrollo compuestos por varios programadores. Los nuevos aspirantes a trabajar en tu grupo deberían antes demostrar de algun modo que poseen los conocimientos suficientes para poder desenvolverse con soltura a la hora de programar código. No vale decir: “Tengo un curso de X y otro de Y”. HAy que saber programar y tener una visión global de lo que es el desarrollo de software.

En conclusión, podemos hacer uso de éste test para:

  1. Puntuar tu modo de desarrollar aplicaciones web o la de la empresa para la que trabajas.
  2. Si eres el jefe de un equipo de programadores, éste test te puede servir como orientación para que puedas conseguir lo máximo de ellos.
  3. Si estás buscando un trabajo como programador web, puedes consultar con tu entrevistador que puntuación obtienen con éste test. En caso de obtener una puntuación baja asegúrate de que tendrás la autoridad suficiente para poder cambiarlo, de lo contrario ten por seguro que te sentirás frustrado trabajando para ellos.

Comments are closed.