Inhoud
Dit is de tweede van een driedelig interview. Jij kan lees hier het eerste deel.
***
Mijn begrip van agile ontwikkeling is redelijk eenvoudig. Ik heb nog nooit gewerkt volgens de methodiek, maar heb hier en daar een beetje over gelezen. Wat is precies een achterstand in de technische schuld?
Een backlog is een takenlijst; maar het is een takenlijst met prioriteiten die om de twee weken opnieuw wordt geprioriteerd (op sprintgrenzen) en de teams committeren zich slechts voor een venster van twee weken (één sprint). Een technische achterstand in de schuldenlast is een subsectie van de totale achterstand en verhalen (taken) die zijn verweven met de algemene achterstand.
Wel, dat zegt me nog geen ton, maar ik heb een snelle google gedaan, een beetje meer gelezen, en heb vastgesteld dat "Technische Schuld is wat code moeilijk maakt om mee te werken. Het is een onzichtbare moordenaar van software, en moet agressief beheerd. " Op basis daarvan denk ik dat ik een aspect van uw werk veel beter begrijp. Moderniseren, brengen tot standaarden, enkele van de oudere code in de EVE Online codebase, zoals wat er vorig jaar met Crimewatch is gebeurd.
Ik weet dat elke vernieuwing van de oude bedrijfs- en POS-code binnenkort niet op de ontwikkelingstabel staat, maar hoe enthousiast zou je zijn als iemand zei: "Laten we dit herschrijven en het goed maken!"
Misschien herinnert u zich de discussies die onlangs rond POSes zijn geweest; CCP Seagull verzorgt de communicatie over dat onderwerp. Ik zou het onderwerp technische schuld kunnen bespreken, maar niet in het kader van POS's.
Eerlijk genoeg. Laten we dit vanuit een andere richting aanpakken. Crimewatch. In alle opzichten een oud, heel fragiel stukje code. Het was heel moeilijk om mee te werken en de meeste projecten vermeden interactie ermee, omdat dit onvoorziene problemen zou kunnen veroorzaken. Toen CCP de beslissing nam om deze code te herschrijven, hoe betrokken was u in het proces dat was gericht op het nieuwe ontwerp? Hoeveel toezicht houdt u op projecten als Crimewatch om ervoor te zorgen dat ze voldoen aan uw normen en dat ze de technische schulden niet opdrijven? Hoe gelukkig was je toen de greenlight werd gegeven om Crimewatch te herschrijven?
Qua technisch ontwerp, niet veel, en niet betrokken bij het ontwerp van de game. De technische leiding voor de gameplayteams (CCP Atlas) en vooral de senior serverprogrammeur (CCP Masterplan) in het team dat het nieuwe systeem implementeerde, waren de mensen in de loopgraven voor het eigenlijke ontwerpwerk. Mijn rol was om te benadrukken dat de oude Crimewatch-code broos was, voorzichtigheidsprogrammeurs en teams die zich in die code waagden en hun werk direct in de gaten hielden, het idee bevorderden dat het moest worden herzien door de kosten aan te tonen die het huidige systeem / de code veroorzaakte en stel de standaarden in voor implementatie en prestatietests (de QA Director is verantwoordelijk voor functietests en algemene testpraktijken).
Ik was heel blij toen dit project eindelijk groen werd; het is altijd goed om deze dingen van de lijst te kunnen halen en vervolgens naar het volgende systeem te gaan.
Ik vind dat de hele technische schuldachterstand een deel van je werk fascinerend maakt, vooral omdat het draait om een groot aantal oude, kern-EVE-systemen waar de spelers moeilijk mee kunnen werken en / of zou willen zien dat ze refactored met betere, modernere functies . CCP is voorzichtig geweest met het aanpakken van deze gebieden van oude, broze code.
Zou het systeem van zakelijke rollen in de technische schuldenachterstand terechtkomen?
Tot op zekere hoogte, maar vooral dat systeem is een kwestie van wat het zou moeten bereiken en vandaar mogelijk een gereviseerd gamedesign afleiden. De code voor dat systeem is niet bijzonder slecht.
"Niet in slechte staat", in welk opzicht? Vanuit het perspectief van een speler is het rollensysteem moeilijk om mee te werken en dingen die mensen zouden verwachten, moeten vaak worden uitgevoerd met verschillende rare oplossingen. (Kelduum heeft een aantal van deze oplossingen in zijn strijd gedocumenteerd om ervoor te zorgen dat de bedrijfsrollen zich op een aantal basismanieren gedragen.) Ik veronderstel dat de code in "goede staat" zou kunnen zijn, gezien wat het eigenlijk was en niet ontworpen was om te doen. De meeste spelers zijn het erover eens dat het een revisie nodig heeft. Is het goed genoeg voor een dergelijke revisie, aan wie is ontwikkelingsprioriteit gegeven?
Ik gebruik "niet in slechte staat" in de context van de technische achterstand van de schuldenlast vanuit een puur technisch aspect. Wat u beschrijft zijn bruikbaarheidsproblemen in het systeem, wat ik noemde "een kwestie van wat het zou moeten bereiken en vandaar mogelijk een gereviseerd spelontwerp afleiden". Vanuit een technisch perspectief is de code zelf niet zo slecht, relatief leesbaar in het grote geheel van dingen en niet slecht gestructureerd.
Wat zijn enkele van de systemen die in de technische schuldenachterstand vallen?
Het kassasysteem, de browser in de game, prestatieverbeteringen voor het opstarten van de client, prestatieverbeteringen voor het verzenden van simulatiegebeurtenissen naar clients aan fysici, prestatieverbeteringen en refactoring van het attribuutsysteem; om er een paar te noemen. Er zijn andere systemen, maar het zijn low-level of interne tools of pijplijnen. Sommige van deze systemen hierboven vallen in meerdere andere categorieën; zoals het kassasysteem heeft bruikbaarheid en ontwerpaspecten, waarvan we sommige in Odyssey aanpakken met verbeteringen van de levenskwaliteit.
Wie neemt de definitieve beslissing over welke items van de technische-schuldachterstand worden aangepakt?
Uiteindelijk is het de Senior Producer die een beroep doet op wat de achterstand voor elke release bevat. Ze zoekt input van verschillende partijen over de prioriteiten en probeert een balans te vinden tussen de verschillende technische en zakelijke behoeften. Items op de Technical Debt Backlog zijn van verschillende groottes en daarom kan een kleinere taak eerder worden gedaan (omdat deze in het schema past), zelfs als deze minder technische prioriteit heeft dan een grotere taak. Waar er significante veranderingen in de spelmechanica zullen zijn, zoals bij Crimewatch, valt dit onder de bevoegdheid van de hoofdgame-ontwerper.
Toch moet je nog steeds een flinke dosis input hebben voor die prioriteiten. Ik kan me voorstellen dat de Senior Producer moet vertrouwen op uw expertise en ervaring met de Technical Debt Backlog?
Als ik weet hoe de Senior Producer de verschillende behoeften moet balanceren, stuur ik haar geen enkele lijst met prioriteiten; ik bespreek eerder de achterstand bij haar en het relatieve belang en de mogelijke omvang van elk project, samen met hoe het doen van bepaalde taken van technische schuldenachterstand andere dingen mogelijk voor haar kan maken en hoe het niet mogelijk is om andere bepaalde taken van de technische schuldachterstand in een hoek te schilderen ".
Worden achterstallige items van Technical Debt behandeld door een bepaald team? Of worden ze uitgedeeld aan teams op basis waarvan ze het best kunnen omgaan (dat wil zeggen teamexpertise)
Ze worden door alle teams afgehandeld, hoewel Team Gridlock alleen betrokken is geweest bij de taken van de technische schuldachterstand, net als de rest van hun achterstand en expertise.
Worden items van Technical Debt Backlog op basis van expansie per expansie aangepakt of zijn ze gewoon aan de gang en zijn ze over het algemeen niet gebonden aan een specifieke uitbreidingscyclus?
Beide.
Welke items met betrekking tot technische achterstand werden aangepakt voor de uitbreiding van Odyssey?
Om er een paar te noemen: We verbeteren het patchen (er is een laag aantal mislukkingen geweest bij het gebruik van HTTP / 1.0 proxies), herschreven het generatieproces van de Image Export Collection en een nieuwe aanpak van foutafhandeling en logging in de EVE API en de invoermethode van de API en het bijwerken van het interne caching-mechanisme (lokaal en gedistribueerd).