Contenu
Ceci est la deuxième d'une interview en trois parties. Vous pouvez lire la première partie ici.
***
Ma compréhension du développement agile est assez basique. Je n'ai jamais travaillé avec la méthodologie, mais j'ai lu un peu à ce sujet ici et là. Qu'est-ce qu'un arriéré de dette technique?
Un backlog est une liste de tâches; mais c'est une liste de tâches hiérarchisée qui peut être redéfinie toutes les deux semaines (sur les limites du sprint) et les équipes ne s'engagent que pour une fenêtre de deux semaines (un sprint). Un arriéré de dette technique est une sous-section de l'arriéré global et des récits (tâches) entrelacés avec l'arriéré général.
Eh bien, cela ne me dit pas une tonne, mais j’ai fait un rapide google, un peu plus de lecture, et j’ai déterminé que "la dette technique est ce qui rend le code difficile à utiliser. C’est un tueur invisible de logiciels, et doit être géré de manière agressive. " Sur cette base, je crois comprendre un aspect de votre travail beaucoup mieux. Moderniser et mettre aux normes certains des codes les plus anciens de la base de codes d’EVE Online, comme ce qui est arrivé à Crimewatch l’année dernière.
Je sais que toute refonte de l'ancien code d'entreprise et du code des points de vente ne fait pas partie du développement, mais à quel point seriez-vous excité si quelqu'un disait: "Réécrivons cela et corrigeons-le!"
Vous vous souvenez peut-être des discussions qui ont eu lieu récemment autour des points de vente; Le PCC Seagull gère la communication à ce sujet. Je pourrais aborder le sujet de la dette technique mais pas dans le contexte des points de vente.
C'est suffisant. Abordons cela dans une autre direction. Montre du crime. De l'avis de tous, c'est un vieux code très fragile. Il était très difficile de travailler avec, et la plupart des projets évitaient d’interagir avec cela, car cela pouvait causer des problèmes imprévus. Lorsque le PCC a pris la décision de réécrire ce code, dans quelle mesure avez-vous participé au processus axé sur la nouvelle conception? Quelle supervision accordez-vous à des projets tels que Crimewatch pour vous assurer qu’ils respectent vos normes et qu’ils n’augmentent pas la dette technique à venir? À quel point étiez-vous heureux lorsque le feu vert a été donné pour réécrire Crimewatch?
En termes de conception technique réelle, pas beaucoup, et pas impliqué dans la conception du jeu. Le responsable technique des équipes de jeu (CCP Atlas) et principalement le programmeur principal (CCP Masterplan) de l'équipe qui a implémenté le nouveau système étaient les personnes dans les tranchées pour le travail de conception proprement dit. Mon rôle était de souligner le fait que l'ancien code de Crimewatch était fragile, avertissent les programmeurs et les équipes qui s'y aventurent et surveillent directement leur travail, promeuvent l'idée qu'il doit être remanié en démontrant le coût que le système / code actuel nous causait et établissent les normes pour les tests de mise en œuvre et de performance (le directeur QA est responsable des tests de fonctionnalité et des pratiques de test générales).
J'étais très heureux lorsque ce projet a finalement été approuvé; Il est toujours bon de pouvoir rayer ces éléments de la liste, puis de passer au système suivant.
Je trouve fascinant tout l’arriéré de dettes techniques de votre travail, d’autant plus qu’il s’articule autour de nombreux anciens systèmes EVE de base avec lesquels les joueurs ont du mal à travailler et / ou aimeraient voir refondus avec des fonctionnalités plus modernes et plus performantes. . Le PCC a pris soin de s’attaquer à ces zones de code ancien et fragile.
Le système de rôle de l'entreprise tomberait-il dans l'arriéré de la dette technique?
Dans une certaine mesure, mais la plupart du temps, ce système est une question de ce qu’il est supposé accomplir et peut en découler une conception de jeu révisée. Le code de ce système n’est pas particulièrement mal en point.
"Pas mal en point", à quel égard? Du point de vue des joueurs, il est difficile de travailler avec le système de rôles et les tâches que les gens attendent normalement doivent souvent être exécutées avec diverses solutions de contournement. (Kelduum a documenté quelques-unes de ces solutions de contournement dans le cadre de ses luttes pour que les rôles de l'entreprise se comportent de manière fondamentale.) Je suppose que le code pourrait être "en bon état" compte tenu de ce qu'il était réellement et de ce qu'il n'avait pas été conçu. La plupart des joueurs s'accorderaient pour dire qu'il a besoin d'une refonte. Est-il en assez bon état pour une telle refonte, a-t-il été donné la priorité au développement?
J'utilise «pas mal en point» dans le contexte de l'arriéré de dette technique d'un point de vue purement technique. Ce que vous décrivez, ce sont des problèmes d’utilisabilité dans le système, ce que j’ai qualifié de «question de ce qu’il est supposé accomplir et à partir duquel peut éventuellement dériver une conception de jeu révisée». D'un point de vue technique, le code lui-même n'est pas si mal, il est relativement lisible dans le grand schéma des choses et pas mal structuré.
Quels sont certains des systèmes qui entrent dans l'arriéré de la dette technique?
Le système de point de vente, le navigateur intégré au jeu, l’amélioration des performances au démarrage du client, l’amélioration des performances pour la distribution d’événements de simulation physique aux clients, l’amélioration des performances et la refactorisation du système d’attributs; pour en nommer quelques uns. Il existe d'autres systèmes, mais ce sont des outils ou des pipelines de bas niveau ou internes. Certains de ces systèmes appartiennent à plusieurs autres catégories. tels que le système de PDV a des aspects de convivialité et de conception, dont nous traitons certains dans Améliorations de la qualité de vie dans Odyssey.
Qui prend la décision finale sur les éléments de l’arriéré de la dette technique qui seront traités?
En fin de compte, c'est le producteur principal qui appelle sur le contenu de l'arriéré de chaque publication. Elle sollicite l’avis de diverses parties sur les priorités et essaie d’équilibrer les divers besoins techniques et commerciaux. Les éléments figurant dans le carnet de commandes de la dette technique sont de tailles différentes. Par conséquent, une tâche plus petite peut être effectuée plus tôt (car elle s’inscrit dans le calendrier), même si sa priorité technique est inférieure à celle d’une tâche plus importante. Là où il y aura des changements significatifs dans les mécanismes du jeu, comme avec Crimewatch, cela relève de la compétence du concepteur du jeu principal.
Même dans ce cas, vous devez toujours avoir votre mot à dire sur ces priorités. J'imagine que le producteur principal doit s'appuyer sur votre expertise et votre expérience de l'arriéré de dette technique?
Sachant que le producteur principal doit équilibrer les différents besoins, je ne lui envoie pas une seule liste de priorités; Je discute plutôt de son arriéré avec elle et de l’importance relative et de la taille possible de chaque projet, ainsi que de la manière dont certaines tâches d’arriéré de dette technique peuvent lui permettre d’autres choses et comment ne pas faire certaines tâches d’arriéré de dette technique peut éventuellement nous «coincer dans un coin». ".
Les éléments de l’arriéré de la dette technique sont-ils gérés par une équipe particulière? Ou sont-ils distribués aux équipes en fonction de ce qui peut le mieux les traiter (savoir-faire de l'équipe)
Ils sont gérés par toutes les équipes, bien que l'équipe Gridlock n'ait été impliquée que dans des tâches d'arriéré de dette technique, selon le reste de son arriéré et de son expertise.
Les arriérés de dette technique sont-ils traités sur une base d'expansion par expansion ou sont-ils simplement en cours et ne sont-ils généralement pas liés à un cycle d'expansion spécifique?
Tous les deux.
Quels éléments de l’arriéré de la dette technique ont été traités pour l’agrandissement d’Odyssey?
Pour en nommer quelques-unes: Nous améliorons les correctifs (il y a eu peu d’échecs lors de l’utilisation de proxy HTTP / 1.0), nous réécrivions le processus de génération de la collection d’exportations et réorganisons la gestion des erreurs, la journalisation dans l’API EVE ainsi que la méthode de déploiement. de l’API et mise à jour de son mécanisme de mise en cache interne (local et distribué.)