Programa de 12 pasos para la recuperación de desarrolladores anónimos - Parte 1

Allá por el año 2000, Joel Spolsky escribió en su blog  un artículo llamado "Los 12 pasos para un mejor código"

programa OK

1. ¿Usan control de fuentes?
2. ¿Se puede compilar en un sólo paso?
3. ¿Se hacen builds diarios?
4. ¿Existe un registro de bugs?
5. ¿Se corrigen bugs antes de escribir código nuevo?
6. ¿Se tiene un plan actualizado?
7. ¿Se tienen requerimientos?
8. ¿Los programadores trabajan en un entorno tranquilo?
9. ¿Se usan las mejores herramientas que se pueden comprar?
10. ¿Hay testers?
11. ¿Los candidatos escriben código en las entrevistas?
12. ¿Se hacen test de "pasillo" de usabilidad?
La idea es responder con un simple sí o no a cada pregunta y se suma un punto si la respuesta es afirmativa. Obviamente, no intenta ser un examen exhaustivo de las falencias de un equipo, sino que simplemente intenta dar una mirada genérica, pero haciendo foco en las características más importantes. 
Según el autor, "un resultado de 12 es perfecto, de 11 es tolerable, pero de 10 o menos indicaría la posibilidad de existencia de problemas. La verdad es que la mayoría de las empresas están entre 2 y 3, y justamente tienen problemas serios".
Este simple test intenta descubrir cuan efectivo es un equipo de desarrollo. Aunque no es su objetivo principal, otros usos posibles podrían ser: evaluar qué cosas uno puede mejorar como desarrollador; medir la calidad de la empresa en la que queremos trabajar y poder considerar diferentes skills de la persona cuando hacemos entrevistas.
Describiré en los siguientes párrafos, cada uno de los pasos desde dos perspectivas. En primer lugar, desde el punto de vista del equipo (como grupo de trabajo persiguiendo un objetivo común) y en segundo lugar, desde la perspectiva personal (de cada individuo como desarrollador y de aquello que está a nuestro alcance para poder mejorar).
1. ¿Usan control de fuentes?
Equipo: teniendo en cuenta que fue escrito en el 2000, el control de fuente era una práctica que venía creciendo, pero realmente aún no había alcanzado los niveles actuales. Recuerdo que en el año 1998, cuando empezaba a trabajar en sistemas, controlábamos la concurrencia de los archivos fuentes cambiando el atributo de "sólo lectura" de los archivos y todas las fuentes se guardaban en un servidor que tenía back up semanal.
Hoy en día no hay ningún motivo para no tener un control de código fuente adecuado para el equipo. GitHub, Visual Studio Online, Bitbucket, TFS, Mercurial, un git local y varias opciones más, hoy nos pueden salvar de tener que recuperar horas y horas de desarrollo por culpa de algún imprevisto.
Personal:tenemos que ser capaces de versionar nuestro trabajo, de recuperar una versión anterior de alguna fuente y entender los conceptos de “Branching” y “Merging”. Después de trabajar mucho tiempo con Visual SourceSafe, me encontré con el cambio a ClearCase, después a Mercurial y por último a Git y TFS, por lo que debemos tratar de mantenernos al día con las tendencias. 
2. ¿Se puede compilar en un sólo paso?
Equipo: se refiere a que, generar una nueva versión de la aplicación, no debería llevar una cantidad de pasos que nos desalienten a querer hacerlas. Es decir, el esfuerzo de tener una nueva aplicación para probar debe ser bajo, y así poder compilar tantas veces como necesitemos en el día sin que ello sea un problema.
Personal: debemos evaluar si tenemos el conocimiento para hacerlo. O sea, si el día de mañana el que hace la compilación no se encuentra disponible, ¿somos capaces de cubrirlo? Si no fuera el caso, entonces nos encontramos ante un punto para trabajar.
3. ¿Se hacen builds diarios?
Equipo: obviamente cada sistema es distinto, pero en la mayoría, deberíamos poder hacer builds diarios, es decir, tomar lo que el repositorio del control de fuentes tenga en ese momento y generar una compilación del sistema. De esta manera, nos aseguramos que el sistema sea consistente en el tiempo, y que los cambios se vayan acomodando todos los días, de modo que, si alguien sube un cambio que espera que no rompa nada, estemos a tiempo de arreglarlo.
Personal: tenemos que conocer el resultado de los builds diarios y poder identificar quiénes son los que trabajaron en la versión que se compiló.
4. ¿Existe un registro de bugs?
Equipo:recordando que Spolsky trabajaba en Fogbuzz, (un reconocido sistema de registro de issues) no es extraño que contemple este punto. De todas formas, el seguimiento de qué errores tenemos identificados en la aplicación es vital para poder tener un plan de corrección y comprobar si el plan general del proyecto es realizable.
Personal: es nuestra tarea saber dónde nos cargan los bugs y cuáles tenemos asignados. Cuando se puede identificar cuáles son los errores que se repiten, es más factible estar pendiente de no cometerlos nuevamente. Por otro lado, es una gran herramienta para conocernos a nosotros mismos y lo que hacemos (o dejamos de hacer) sin ser conscientes.
5. ¿Se corrigen bugs antes de escribir código nuevo?
Equipo: dependiendo del tipo de proyecto, uno tiene el momento para corregir los bugs durante el mismo desarrollo, mientras que en otros proyectos deberá esperar hasta tener el OK para avanzar. De todas formas, es muy necesario tener planificado cuando se encararán los bugs.
Personal: sabemos que cuando el día laboral va llegando a su fin, somos más propensos a "probar cosas" que no son del todo prolijas. Además, muchas veces se piensa "lo arreglo después cuando tenga tiempo". Pero si uno toma por costumbre revisar al inicio del día siguiente si hay cosas mejorables del día anterior, el código se vuelve "mejor" sin tener que esperar un momento particular para revisar y arreglar todo (que generalmente nunca sucede).
6. ¿Se tiene plan actualizado?
Equipo: tenemos que saber en cualquier momento qué hicimos, qué estamos haciendo y qué vamos a hacer. Tener un plan, seguirlo y actualizarlo nos da esta visibilidad, nos ayuda a planear las vacaciones, a descubrir si hay problemas o si vamos a tenerlos, etc.
Personal: las tareas de un desarrollador normalmente incluyen: ser metódico al terminar un desarrollo y no dejar de testearlo, commitearlo en el repositorio, actualizarlo en el plan y poner al tanto al resto del equipo. Justamente, para comunicar al resto del equipo, si nosotros somos consistentes al mantener el estado de nuestras tareas al día, disminuyen las interrupciones que tendremos para saber el avance de una tarea.  Por último, esto nos da la posibilidad de prever a tiempo si necesitamos ayuda de alguien más.
Continuará…
 
Autor: 
 
Marcelo Mosquera
Technical Expert at Baufest

Contacto

info@baufest.com