En esta ocasión me di la oportunidad de escuchar el podcast 2 veces. La primer ocasión por mi cuenta de manera corrida, y la segunda ocasión acompañado haciendo pausas y (puesto que la persona con la que lo escuche es ajena a la carrera) compartiendo perspectivas y aplicaciones de algunos de los comentarios que se realizaron en la entrevista.
Al día siguiente, horas tarde en la oficina mientras avanzaba con algunos pendientes que tenia, aproveche y vi en Youtube un vídeo sobre el creador de Dead Space que nos platicaba sobre los retos a los que se enfrento él y su equipo a la hora de realizar el juego y me di cuenta que muchos de estos problemas se resolvían por puntos híbridos tocados en el podcast.
Desde la manera de planear el problema, tenia una idea completa de cierta escena del juego y al querer resolverlo todo de un mismo jalón, las cosas simplemente no embonaban, eran como piezas de ajedrez de diferentes sets y tomó la decisión de empezar de cero (esta metodología) y desglosar las cosas por capas. Entonces (aunque me consta no igual) iban atacando punto por punto. Hacían que cierto task funcionara, seguían a partir de ahí. No seria algo, vamos para atrás pero en el pequeño ultimo punto que funcionó y así sucesivamente hasta que lograron terminar la gran escena de una lombriz zombie alienigena gigante que agarra a nuestro personaje.
Retroalimentando un poco mi idea de como muchas practicas y metodologías aplicadas al software tienen su pariente de aplicación en otras áreas de la industria platique el viernes con nuestro profesor Ken Bauer y me comenta como a el le pasaba que a pesar de ser un tema que hablaba y sugería desde hace 20 años, constantemente se encontraba con personas que recomendaban un libro donde hablaba de esta metodología. Un poco cuando en la primaria decías un chiste y nadie te escuchaba, y el compañero de al lado que si te contestó lo repite y todos se ríen. Duele pero al menos, las risas no faltaron ¿no?
Ahora volviendo al tema, TC | R. ¿Funciona? en resumen, puedo decir que he adoptado esta metodología involuntariamente acostumbrando a trabajar modular-mente por features individuales. Sin embargo por el tipo de trabajo que realizo, no me es posible hacer commits | reverts. Lo más cercano que puedo hacer es tener mi control de versiones diaria con documentación de todos los cambios que se han ido involucrando, desgraciadamente si llegase a ocurrir algo que corrompa mi proyecto, a menos que haya hecho un zipup del proyecto recientemente por (misma precaución) algún cambio mayor, tendria que regresar a hacer los cambios hechos el mismo día. Y créanme, me ha pasado más de alguna vez, lo cual me ha obligado a constantemente mejorar mi metodología y saber cuando hacer copias extra. Mi mismo dolor y experiencia les aconseja !HÁGANLO!, más vale prevenir. Y es cierto, así se comentaba en el podcast, hay ciertas situaciones donde esta metodología no funciona tan bien como en un proyecto individual compatible con git. Hay proyectos donde se involucran equipos de personas muy grandes donde para cada cambio hay un protocolo de revisión y aprobación y si se espera a que cada uno de estos commits pase por eso, puede prolongar el tiempo de desarrollo mucho mayor. Será cuestión simplemente de ver que tan compatible es con el proyecto de cada uno pero sin duda es una metodología que vale la pena revisar. Por la parte de testing que tienes también te ayuda a saber que parte del nuevo pequeño cambio fue lo que arruino que cosas.
Por lo pronto es todo, y a las personas que no tengan acceso a ese podcast les adjunto el link.
Y recuerden, si mis test pasaron, !COMMIT!
por Adler Alonso Zamora Ruiz alias Tepic Guy
adlerzamora.wordpress.com 
Comentarios recientes