@ agnasg

git, fossil, unit testing

14-04-2018 6:30 AM

Estaba leyendo este artículo de la gente de SQLite, sobre por qué ellos no usan git, y por un momento pensé que era una buena idea estudiar fossil, que es lo que ellos usan. Y cuando digo un momento me refiero a 5-10 segundos, porque fossil, como es de imaginar, tiene su propia curva de aprendizaje, que es como todas las curvas de aprendizaje, una curva, con una excentricidad pronunciada. Así que como estoy en una onda de dedicarme a la programación de juegos y no a las herramientas para “ayudar” a programar, abandoné la idea. Por cierto que khpx usa por lo pronto SQLite para guardar los datos. Yo he desarrollado varias bases de datos portátiles, pero SQLite es insuperable en términos de eficiencia y confiabilidad. Como quiera que sea, khpx continúa sin un sistema de versiones (version control).

Y eso es grave.

Yo usé git con uno de mis zombies (un juego al que le dediqué una considerable cantidad de tiempo y no he publicado) y nunca descubrí el genuino beneficio de usarlo, más allá de la obstinación con sus rarezas y excentricidades (sabía que esa palabra tenía otra acepción). Actualmente hago respaldos para cubrirme las espaldas (¿por qué decimos eso si solamente tenemos una espalda) en caso de una pérdida, pero también para hacer el backtracking que me permita descubrir la naturaleza y orígen de un bug. Y eso es horrible. Identificar cuándo comenzó a aparecer un bug puede ser complicado e inútil con un sistema de respaldo, e inclusive con un sistema de versiones. git (y me imagino que fossil) tiene mecanismo de ayuda, pero solamente si lo usas en forma adecuada. Y eso consume tiempo. Hay un compromiso entre el tiempo que le dedicas a la preparación para una recuperación de desastre (corregir un bug) y el tiempo que le dedicarías si no te preparas en lo absoluto y lo haces con fuerza bruta. O con tus neuronas.

Y hay bugs que van a requerir todas y cada una de tus neuronas.

El último de estos bugs me sucedió esta semana. El ciclo del rendering es la parte crucial de todo el game loop (“el lazo del juego” no traduce todos los intrilinguis de “game loop”) . Inadvertidamente coloqué una llamada en el lugar incorrecto, y ¡bang!, perdí 30fps en el proceso (khpx está en 62fps, el bug lo redujo a 30fps). Luego de pasar un par de horas con los respaldos era evidente que no lo iba a descubrir de esa forma. En posible que con el sistema de versiones tampoco. Así que tuve que pensar. Durante 5 minutos, completos, largos y difíciles de incertidumbre y temor. Lo resolví, pero ¿cómo pudo suceder? ¿cómo fue que no me di cuenta del problema? Porque no solamente no tengo control de versiones sino porque el sistema de pruebas es muy rudimentario.

¿Qué aprendí? Nada que no supiera de antemano, necesito un sistema de versiones, un sistema robusto de pruebas, no dejar pasar cosas obvias (estar pendiente de) como un impacto en los valores de desempeño del juego, por ejemplo los fps. Lo único que voy a hacer por ahora es mejorar todo el sistema alrededor del cálculo del fps (ahora se despliega el promedio) y colocar una alarma cuando este promedio está por debajo (en forma consistente) con el normal. git, fossil, unit testing, siguen en pendiente.