Contenido
Esta es la segunda de una entrevista en tres partes. Usted puede lee la primera parte aqui.
***
Mi comprensión del desarrollo ágil es bastante básica. Nunca he trabajado bajo la metodología, pero he leído un poco sobre esto aquí y allá. ¿Qué es exactamente una acumulación de deuda técnica?
Un backlog es una lista de tareas; pero es una lista de tareas priorizadas que puede volver a priorizarse cada dos semanas (en los límites del sprint) y los equipos solo se comprometen por una ventana de dos semanas (un sprint). Una acumulación de deuda técnica es una subsección de la cartera general y las historias (tareas) que se intercalan con la cartera general.
Bueno, eso no me dice ni una tonelada, pero hice una búsqueda rápida en Google, leí un poco más y determiné que "la deuda técnica es lo que hace que sea más difícil trabajar con el código. Es un software que mata de forma invisible, y debe ser gestionado agresivamente ". En base a eso, creo que entiendo mucho mejor un aspecto de su trabajo. Modernizando, ajustando a los estándares, algunos de los códigos más antiguos en el código base de EVE Online, como lo que le sucedió a Crimewatch el año pasado.
Sé que cualquier renovación del antiguo código corporativo y de POS no está en la lista de desarrollo en el corto plazo, pero ¿qué tan emocionado estaría si alguien dijera "Reescribamos esto y hagámoslo bien?"
Puede recordar las discusiones que ocurrieron alrededor de POS recientemente; CCP Seagull maneja la comunicación sobre ese tema. Podría discutir el tema de la deuda técnica pero no en el contexto de los POS.
Lo suficientemente justo. Vamos a abordar esto desde una dirección diferente. Crimewatch. Por todas las cuentas un viejo, muy frágil pieza de código. Era muy difícil trabajar con él, y la mayoría de los proyectos evitaban interactuar con él, ya que podía causar problemas imprevistos. Cuando CCP tomó la decisión de volver a escribir este código, ¿qué tan involucrado estuvo en el proceso que se centró en el nuevo diseño? ¿Cuánta supervisión le da a proyectos como Crimewatch para asegurarse de que cumplan con sus estándares y que no aumenten la deuda técnica en el futuro? ¿Qué tan feliz estabas cuando se le dio luz verde para reescribir Crimewatch?
En términos del diseño técnico real, no mucho, y no involucrado en el diseño del juego. El líder técnico de los equipos de juego (CCP Atlas) y principalmente el programador senior de servidores (CCP Masterplan) en el equipo que implementó el nuevo sistema fueron las personas en las trincheras para el trabajo de diseño real. Mi función fue resaltar el hecho de que el antiguo código de Crimewatch era frágil, los programadores y equipos de precaución que se aventuraron en ese código y monitorearon directamente su trabajo, promovieron la idea de que se debe reformular demostrando el costo que el sistema / código actual nos estaba causando. y establecer los estándares para la implementación y las pruebas de rendimiento (el director de control de calidad es responsable de las pruebas de características y las prácticas generales de las pruebas).
Me sentí muy feliz cuando este proyecto fue finalmente iluminado; siempre es bueno poder tachar estas cosas de la lista y luego pasar al siguiente sistema.
Considero que toda la parte de la deuda técnica de su trabajo es fascinante, especialmente porque gira en torno a muchos sistemas EVE centrales antiguos con los que a los jugadores les resulta difícil trabajar y / o les gustaría ver refaccionados con características mejores y más modernas . CCP ha sido cuidadoso al abordar estas áreas de código antiguo y quebradizo.
¿Caería el sistema de rol corporativo en la acumulación de deuda técnica?
Hasta cierto punto, pero sobre todo ese sistema es una cuestión de lo que se supone que debe lograr y, a partir de ahí, posiblemente se derive de un diseño de juego revisado. El código para ese sistema no está particularmente en mal estado.
"No está en mal estado", ¿en qué sentido? Desde la perspectiva de un jugador, es difícil trabajar con el sistema de roles, y las cosas que la gente espera que haga, a menudo tienen que realizarse con varias soluciones extrañas. (Kelduum ha documentado algunas de estas soluciones en sus luchas para lograr que los roles corporativos se comporten de alguna manera básica). Supongo que el código podría estar en "buena forma" dado lo que realmente fue y no fue diseñado para hacer. La mayoría de los jugadores estarían de acuerdo en que se necesita una revisión. ¿Está lo suficientemente bien como para una revisión de este tipo, si se le diera prioridad de desarrollo?
Estoy usando "no en una mala forma" en el contexto de la acumulación de deuda técnica desde un aspecto puramente técnico. Lo que estás describiendo son problemas de usabilidad en el sistema, a lo que me refiero como "una pregunta de lo que se supone que debe lograr y de ahí posiblemente derivar un diseño de juego revisado". Desde una perspectiva técnica, entonces el código en sí no es tan malo, comparativamente legible en el gran esquema de las cosas y no está mal estructurado.
¿Cuáles son algunos de los sistemas que caen en la acumulación de deuda técnica?
El sistema POS, el navegador del juego, las mejoras de rendimiento para el inicio del cliente, las mejoras de rendimiento para enviar eventos de simulación física a los clientes, las mejoras de rendimiento y la refactorización del sistema de atributos; para nombrar unos pocos. Hay otros sistemas, pero son herramientas internas o de bajo nivel o herramientas. Algunos de estos sistemas anteriores se clasifican en otras categorías; como el sistema POS tiene aspectos de usabilidad y diseño, algunos de los cuales estamos abordando en Odyssey con mejoras en la calidad de vida.
¿Quién toma la decisión final sobre qué elementos de la acumulación de deuda técnica se abordarán?
En última instancia, es el Productor principal el que hace una llamada sobre lo que contiene el trabajo acumulado de cada versión. Solicita la opinión de varias partes sobre las prioridades y trata de equilibrar las diversas necesidades técnicas y comerciales. Los elementos en la acumulación de deuda técnica son de varios tamaños y, por lo tanto, una tarea más pequeña se puede realizar antes (porque se ajusta al cronograma) incluso si tiene menos prioridad técnica que una tarea más grande. Donde habrá cambios significativos en la mecánica del juego, como con Crimewatch, esto cae bajo el alcance del diseñador de juegos principal.
Aun así, todavía debe tener un poco de información sobre esas prioridades. Me imagino que el Productor Principal debe confiar en su experiencia y experiencia con la acumulación de deuda técnica.
Sabiendo cómo el Productor Principal necesita equilibrar las diferentes necesidades, entonces no le envío una sola lista de prioridades; más bien, discuto el trabajo atrasado con ella y la importancia relativa y el tamaño posible de cada proyecto, junto con la forma en que hacer ciertas tareas del Registro Técnico de Deudas puede permitirle otras cosas y cómo no hacer otras tareas determinadas puede llevarnos a un rincón. ".
¿Los artículos de la acumulación de deuda técnica son manejados por un equipo en particular? O se entregan a los equipos en función de la mejor manera de tratar con ellos (es decir, la experiencia del equipo)
Son manejados por todos los equipos, aunque Team Gridlock ha estado involucrado solo en tareas de Backlog de deuda técnica, como corresponde al resto de su backlog y experiencia.
¿Se abordan los elementos de la acumulación de deuda técnica en una base de expansión por expansión, o simplemente están en curso, y no están generalmente vinculados a un ciclo de expansión específico?
Ambos.
¿Qué elementos de la acumulación de deuda técnica se abordaron para la expansión de Odyssey?
Para mencionar algunos: estamos mejorando la aplicación de parches (ha habido un bajo número de fallas al usar proxies HTTP / 1.0), reescribimos el proceso de generación de la Colección de exportación de imágenes y renovamos el manejo y el registro de errores en la API de EVE, así como el método de implementación de la API y actualizando su mecanismo interno de caché (local y distribuido).