Escribiendo mejor código para proyectos basados en WordPress
No recuerdo exactamente cuándo me encontré por primera vez con el blog Joel on Software de Joel Spolsky, pero fue en algún momento a finales de la escuela secundaria.
No sabía lo suficiente sobre todo el proceso de desarrollo de software para entender mucho de lo que realmente estaba hablando, pero disfruté su estilo de escritura y disfruté lo que tenía que decir.
De hecho, era tan fanático que cuando me gradué, compré sus libros (que eran colecciones de los artículos en su sitio) y los leí de cabo a rabo. Guardé copias de ellos en mi escritorio en el trabajo, y usé uno de sus libros, Smart and Gets Things Done, cuando era líder de equipo.
Sin embargo, los artículos que más me llamaron la atención fueron los que trataban de escribir mejor código. Sin embargo, aquí está la cosa: esos artículos no incluían nada sobre escribir código.
Escribir mejor código
En cambio, se trataba de los procesos en torno a un mejor código. Y me topé con un artículo, de 16 años, sin embargo, y todavía lo encuentro tan relevante hoy como lo hice cuando lo encontré por primera vez.
Excepto que ahora, me pregunto cómo se aplica a mi trabajo de desarrollo actual.
La prueba de Joel
Primero, el artículo en cuestión es uno que me encuentro leyendo al menos una vez al mes -si no al menos una vez a la semana- y todo gira en torno a lo que él llama The Joel Test. Son doce preguntas que aplica a su equipo de desarrollo actual.
- ¿Usas control de fuente?
- ¿Se puede hacer una acumulación en un solo paso?
- Haces contrucciones todos los dias.
- ¿Tienes una base de datos de errores?
- ¿Tú arreglas los errores antes de escribir un nuevo código?
- ¿Tienes un horario actualizado?
- ¿Tiene una especificación?
- ¿Los programadores tienen condiciones de trabajo tranquilas?
- Utilizas las mejores herramientas que el dinero puede comprar?
- Tienes probadores?
- ¿Los nuevos candidatos escriben código durante su entrevista?
- ¿Hacen pruebas de usabilidad en los pasillos?
Dado que estas preguntas se escribieron hace 16 años y se basan en gran medida en código compilado, es posible que sea necesario ajustar parte de la terminología.
Lo bueno de The Joel Test es que es fácil obtener un rápido sí o no a cada pregunta. No tiene que averiguar las líneas de código por día o el promedio de errores por punto de inflexión. Dale a tu equipo 1 punto por cada respuesta "sí".
Por ejemplo, en lugar de preguntar si puede hacer una compilación en un solo paso, tal vez deberíamos preguntarle si podemos hacer una implementación en un solo paso. Ya sabes a lo que me refiero: hacer ajustes a cosas como esa.
En segundo lugar, algunas de las preguntas deben adaptarse a equipos remotos porque ya no estamos todos en la misma oficina. Es decir, en lugar de realizar pruebas de usabilidad en el pasillo, es posible que deba buscar a alguien que conozca en línea, enviarlo a su entorno de prueba y preguntarle sobre el proyecto.
La prueba de Joel para WordPress
Tal vez, para aquellos de nosotros que usamos WordPress como nuestra base de desarrollo, nuestro conjunto de preguntas se vería así:
- ¿Usas control de fuente?
- ¿Se puede hacer una implementación en un solo paso?
- ¿Hacéis despliegues diarios?
- ¿Tienes una base de datos de errores?
- ¿Tú arreglas los errores antes de escribir un nuevo código?
- ¿Tienes un horario actualizado?
- ¿Tienes requisitos y maquetas?
- ¿Los programadores tienen condiciones de trabajo tranquilas? O, si son remotos, ¿se les permite a los programadores entrar en el modo "No molestar"?
- ¿Utiliza las mejores herramientas del mercado, ya sea algo gratuito y de código abierto o algo premium?
- Tienes probadores? (Y podría preguntar si el presupuesto para el proyecto también permite tiempo para escribir pruebas unitarias para pruebas automatizadas).
- ¿Los candidatos tienen muestras de código disponibles en GitHub, un blog o una ubicación disponible públicamente que se pueda revisar?
- ¿Tiene un grupo de personas de las que puede extraer para probar su trabajo en progreso?
Una vez más, esto se basa en gran medida en la idea de un equipo pequeño y remoto en lugar de una gran empresa o agencia de productos de nivel empresarial. Pero es algo a lo que todavía vuelvo de vez en cuando y me pregunto cómo se comparan otras tiendas entre sí.
Ah, ¿y todo el asunto de la puntuación?
Una puntuación de 12 es perfecta, 11 es tolerable, pero 10 o menos significa que tienes serios problemas. La verdad es que la mayoría de las organizaciones de software se ejecutan con una puntuación de 2 o 3, y necesitan ayuda seria…
Todos tenemos algo a lo que apuntar, ¿verdad?
¿Para la próxima década?
No es tanto que piense que es una competencia, pero sé que me gustaría poder responder afirmativamente a la mayoría de estas preguntas para mí y para aquellos con quienes trabajo.
Pero en el momento de este artículo, puedo decir que no puedo decir que sí a todos estos, y mucho menos a la mitad de ellos. Sin embargo, tal vez para fin de año, pueda hacerlo.
Y tal vez el resto de los que trabajamos en la industria podamos evaluar a nuestros equipos frente a estas preguntas. Aunque Internet y las tecnologías relacionadas se mueven rápido, estas preguntas se han mantenido bien durante más de una década.