Desarrollando sin QA #1

No es ningún secreto que Vessel se está desarrollando con mucha pasión, conocimiento, y una falta terrible de financiación y miembros esenciales del equipo. En el post de hoy veremos cómo estamos gestionando la calidad del código en un desarrollo sin ningún miembro del equipo dedicado a esta función.

Crasheando lo antes posible

En el mundo del desarrollo de software hay dos grandes escuelas. La primera estipula que el programa (en este caso, Vessel) siempre debe ser estable y funcional. Debido a ello, la gran mayoría de esfuerzos van a asegurarse que esto es así y nunca hay un pete (o crash). La segunda consiste en ser extremadamente dramáticos y considerar que cada pequeño contratiempo debe ser fatal y en consecuencia crashear el programa. Ambas escuelas són útiles en determinados casos y pese a las bromas, por ahora Vessel usa la segunda.

La primera escuela (la de la programación defensiva) es una solución muy interesante para productos que ya se han lanzado, tengan esfuerzos dedicados de mantenimiento, y un equipo grande de QA. Hoy en día es casi un estándar en todo el software que depende de un público amplio. ¡Nadie quiere que Netflix, Windows, o Word crasheen! Para evitarlo, los programadores tratan todo como una posible amenaza, añadiendo excepciones y contingencias para cualquier situación. El departamento de QA es esencial para ayudar a entender que cosas pueden ir mal y adelantarse a ellas. Pero Vessel no tiene QA, apenas si tenemos programadores, así que esta metodología es poco práctica.

La segunda escuela nos sugiere que hagamos justo lo contrario. A la mínima que detectamos que hay algo mal rompemos Vessel por completo. Esto presenta dos grandes ventajas:

1. Hace que el hecho de que haya un error sea obvio.

2. Evita que los errores progresen y se enquisten dando pie a situaciones más complejas de resolver.

Veamos un ejemplo:

Digamos que añadimos un arma nueva al juego y nos olvidamos de vincularle un archivo de configuración que controla el tiempo de enfriamiento. Siguiendo los preceptos de la primera escuela habremos añadido un valor por defecto para que en caso de que ocurra algo podamos seguir jugando. Digamos que por desgracia este valor por defecto es casi igual al valor que queremos dar, digamos que el valor por defecto es 0,1 segundos y el valor deseado era de 0,12. Al ser tan cercanos nadie se da cuenta del error en ese momento. Más adelante implementamos un enemigo que solo se puede matar haciendo una cantidad X de daño en un tiempo determinado Y. Este enemigo que ha sido balanceado teniendo en cuenta un enfriamiento de 1,0 es, de golpe, es imposible de matar.  

Si tienes suerte y pasa todo más o menos a la vez puede que resuelvas el problema rápido. Si no es así, lo más probable es que nadie piense que el problema está en el arma.

Siguiendo la segunda escuela, lo que hacemos es comprobar que el arma está bien durante su inicialización, como en este caso esta comprobación fallaria, el juego crashea. El error se hace obvio y por lo tanto la situación no va a más.

Dando sentido a los crashes

Entiendo que por el ejemplo anterior puede parecer que mi opinión se inclina más hacia esta segunda escuela. La realidad es que soy una persona pragmática y en este caso en particular soy bastante neutral. Bajo mi punto de vista estos són los problemas principales que acarrea esta aproximación:

1. Si no se gestiona bien cada error, por pequeño o estupido que sea, puede bloquear al equipo.

   1. Como se que eres un lector avispado, si esto puede resolverse con las feature flags de las que hablamos en un post anterior. 

2. Diferentes entornos de ejecución pueden provocar distintos errores y falsos positivos. En este caso, el juego no se ejecuta igual compilado que en el editor. Esto puede hacer que aparezcan errores en la build que no se ven en el editor y viceversa.

3. El crash hace obvio que hay un error pero no hace necesariamente que el error sea obvio.

El segundo y tercer punto se pueden mitigar de una forma muy simple. Escribiendo errores con sentido. Con esto me refiero a exponer porque rompemos el juego para gente que no es técnica y si es posible como solucionar el error. 

Volviendo al ejemplo anterior, si el mensaje es una aserción críptica escrita en pseudocódigo o un código de error, lo más probable es que se necesite a un programador para solucionarlo. Sin embargo si el mensaje dice algo como: “No se ha podido inicializar el arma A debido a la falta del fichero B en el campo C. Por favor revisa la configuración del asset!” cualquiera que tenga acceso al editor puede solucionar el error. Si el mensaje es claro da igual donde o cuando aparezca el error, siempre será más fácil de solucionar que en el primer caso.

En definitiva, como equipo hemos optado por esta forma de trabajar para evitar problemas más difíciles en un futuro a medio plazo. Entonces ¿Podremos sacar adelante el juego sin QA? En absoluto. Siempre se necesita QA, pero hemos ganado algo de tiempo. Con suerte habremos ganado suficiente tiempo como para conseguir financiación y contratar a alguien.  

Como habrás deducido por el título, este es el primero de una serie de posts donde explicaré cómo mitigamos la ausencia de uno de los roles más críticos. ¡Suscríbete para no perderte los próximos! Comparte este post, deja un like, y si te gusta este tipo de contenido plantéate hacer una donación en Ko-fi para ayudarme a que la web siga abierta. ¡Hasta la próxima!