Indhold
Dette er den anden af et tre-delt interview. Du kan læs det første afsnit her.
***
Min forståelse for fleksibel udvikling er ret grundlæggende. Jeg har aldrig arbejdet under metoden, men har læst lidt om det her og der. Hvad er en teknisk gældsforbindelse?
En backlog er en opgaveliste; men det er en prioriteret opgaveliste, der kan få prioriteret hver anden uge (på sprintgrænser) og holdene forpligter sig kun til et to uger vindue (en sprint). En teknisk gældsforventning er en del af den samlede efterslæb og historier (opgaver), der er sammenflettet med den generelle efterslæb.
Tja, det fortæller mig ikke et ton, men jeg gjorde en hurtig google, lidt mere læsning og har fastslået, at "Teknisk gæld er det, der gør kode svært at arbejde med. Det er en usynlig morder af software og skal være aggressivt styret. " På den baggrund tror jeg jeg forstår et aspekt af dit job meget bedre. Modernisering, opbygning af standarder, nogle af de ældre kode i EVE Online-kodebase, som hvad der skete med Crimewatch sidste år.
Jeg ved, at nogen ny opgradering af den gamle virksomhedskode og POS-kode ikke er på udviklingsskiferet, når som helst snart, men hvor spændt ville du være, hvis nogen sagde "Lad os omskrive dette og gøre det rigtigt!"
Du kan huske de diskussioner, der skete for nylig omkring POSes; CCP Seagull håndterer kommunikation om dette emne. Jeg kunne diskutere emnet for teknisk gæld, men ikke i forbindelse med POSes.
Fair nok. Lad os takle dette fra en anden retning. Crimewatch. Af alle konti et gammelt, meget skrøbeligt stykke kode. Det var meget svært at arbejde sammen med, og de fleste projekter undgik at interagere med det, fordi det kunne medføre uforudsete problemer. Når CCP tog beslutningen om at omskrive denne kode, hvor involveret var du i gang med at fokusere på det nye design? Hvor meget tilsyn giver du projekter som Crimewatch for at sikre, at de er i overensstemmelse med dine standarder, og at de ikke tilføjer teknisk gæld ned ad vejen? Hvor glad var du, da greenlight blev givet til at omskrive Crimewatch?
Med hensyn til det faktiske tekniske design, ikke meget, og ikke involveret i spildesign. Den tekniske ledelse for spillets legeteam (CCP Atlas) og primært den senior serverprogrammerer (CCP Masterplan) i teamet, der implementerede det nye system var folkene i skyttegravene til det faktiske designarbejde. Min rolle var at fremhæve den kendsgerning, at den gamle Crimewatch-kode var sprød, forsigtige programmører og hold, der vovede ind i den kode og direkte overvåger deres arbejde, fremmer ideen om, at den burde refactored ved at demonstrere omkostningerne, som det nuværende system / kode forårsagede os , og sæt standarderne for implementering og præstationsprøvning (QA-direktøren er ansvarlig for funktionstest og generelle testpraksis).
Jeg var meget glad, da dette projekt endelig blev lyset; Det er altid godt at kunne krydse disse ting fra listen, og derefter gå videre til det næste system.
Jeg finder den samlede tekniske gældsforhalning del af dit job fascinerende, især fordi det drejer sig om mange gamle, centrale EVE-systemer, som spillerne har svært ved at arbejde med og / eller gerne vil se refactored med bedre og mere moderne funktioner . KKP har været forsigtig med at tackle disse områder af gammel, skør kode.
Ville virksomhedernes rolle system falde ind i den tekniske gældsforpligtelse?
I et vist omfang, men for det meste er systemet et spørgsmål om, hvad det skal udføre og derfra muligvis udlede et omhyggeligt spildesign. Koden for dette system er ikke særlig dårlig.
"Ikke i dårlig form", i hvilken henseende? Fra et spillerperspektiv er rollesystemet vanskeligt at arbejde med, og ting, som folk ville forvente det, skal ofte udføres med forskellige ulige løsninger. (Kelduum har dokumenteret nogle af disse løsninger i sine kampe får virksomhedernes roller til at opføre sig på nogle grundlæggende måder.) Jeg antager, at koden kunne være i "god form" i betragtning af hvad det egentlig var og ikke var designet til at gøre. De fleste spillere vil være enige om, at der er behov for en revision. Er det i god nok form for en sådan revision, blev den givet udviklingsprioritet?
Jeg bruger "ikke i en dårlig form" i sammenhæng med den tekniske gældsbistand fra et rent teknisk aspekt. Hvad du beskriver, er brugervenlighedsproblemer i systemet, hvad jeg omtalte som "et spørgsmål om, hvad det skal udføres og derfra muligvis udlede et gennemgået spildesign". Ud fra et teknisk synspunkt er koden i sig selv ikke så dårlig, relativt læsbar i det store skema af ting og ikke dårligt struktureret.
Hvad er nogle af de systemer, der falder ind i den tekniske gældsbidrag?
POS-systemet, browserens browser, forbedringer af ydeevnen til klientens opstart, forbedringer af ydeevnen til at sende fysik simuleringshændelser til klienter, ydeevne forbedringer og refactoring af attributtsystemet; for at nævne et par stykker. Der er andre systemer, men de er enten lavt niveau eller internt værktøj eller rørledning. Nogle af disse systemer falder ind i flere andre kategorier; såsom POS-systemet har brugervenlighed og design aspekter, hvoraf nogle vi adresserer i Odyssey med kvalitetsforbedringer.
Hvem træffer den endelige beslutning om, hvilke tekniske gældsbegrænsningsposter der vil blive taget fat på?
I sidste ende er det Senior Producent, der kalder på, hvad bagagen for hver udgivelse indeholder. Hun søger input fra forskellige parter om prioriteterne og forsøger at afbalancere de forskellige tekniske og erhvervsmæssige behov. Poster på den tekniske gældsforpagtning har forskellige størrelser, og derfor kan en mindre opgave blive gjort tidligere (fordi det passer ind i tidsplanen), selvom der er mindre teknisk prioritet end en større opgave. Hvor der vil være væsentlige ændringer i spilmekanikken, som med Crimewatch, falder dette under ledelsesdesigners design.
Alligevel skal du stadig have en rimelig indsats på disse prioriteter. Jeg kan forestille mig, at Seniorproducenten skal stole på din ekspertise og erfaring med den tekniske gældsbidrag?
At vide, hvordan seniorproducenten skal balancere de forskellige behov, så sender jeg ikke hende en enkelt prioriteret liste; snarere diskuterer jeg efterslæbet med hende og den relative betydning og mulige størrelse af hvert projekt sammen med, hvordan man gør visse tekniske gældsopgaver, kan muliggøre andre ting for hende, og hvordan man ikke gør andre bestemte tekniske gældsopgaver kan muligvis "male os i et hjørne ".
Er tekniske gældsbegrænsningsposter behandlet af et bestemt hold? Eller udleveres de til hold baseret på, som bedst kan håndtere dem (dvs. teamekspertise)
De håndteres af alle holdene, selvom Team Gridlock kun har været involveret i Technical Debt Backlog-opgaver, som passer til resten af deres efterslæb og ekspertise.
Er tekniske gældsbegrænsningsposter behandlet på en ekspansions-for-ekspansionsbasis, eller er de simpelthen igangværende og ikke generelt bundet til en bestemt ekspansionscyklus?
Begge.
Hvilke tekniske gældsbegrænsningsposter blev tacklet for Odyssey-ekspansion?
For at nævne nogle få: Vi forbedrer patching (der har været et lille antal fejl ved brug af HTTP / 1.0 proxies), omskrivning af generationsprocessen for Image Export Collection og omfordeling af fejlhåndtering og logning i EVE API samt implementeringsmetoden af API'en og opdatering af dens interne caching mekanisme (lokal og distribueret.)