Innehåll
Detta är den andra av en trepartsintervju. Du kan läs den första delen här.
***
Min förståelse för smidig utveckling är ganska grundläggande. Jag har aldrig arbetat med metodiken, men har läst lite om det här och där. Vad är exakt en teknisk skuldstock?
En backlog är en arbetslista; men det är en prioriterad arbetslista som kan få prioriterad vartannat vecka (på sprintgränser) och lagen förbinder sig bara för ett tvåveckors fönster (en sprint). En eftersläpning av teknisk skuld är en del av den övergripande eftersläpningen och berättelserna (uppgifter) som sammanfaller med den allmänna eftersläpningen.
Tja, det säger inte mig ett ton, men jag gjorde en snabb google, lite mer läsning och har bestämt att "Technical Debt är vad som gör kod svårt att arbeta med. Det är en osynlig mördare av programvara och måste vara hanteras aggressivt. " Utifrån det tror jag att jag förstår en aspekt av ditt jobb mycket bättre. Modernisering, uppföljning av standarder, en del av den äldre koden i EVE Online-kodbasen, till exempel vad som hände med Crimewatch förra året.
Jag vet att någon uppgradering av den gamla företags- och POS-koden inte är på utvecklingsskiffer när som helst snart, men hur upphetsad skulle du vara om någon sa "Låt oss skriva om det här och göra det rätt!"
Du kanske kommer ihåg diskussionerna som hände nyligen om POSes; CCP Seagull hanterar kommunikation om det ämnet. Jag kunde diskutera ämnet teknisk skuld men inte i samband med POSes.
Rimligt nog. Låt oss ta itu med detta från en annan riktning. Crimewatch. Av alla konton en gammal, mycket bräcklig kod. Det var mycket svårt att arbeta med, och de flesta projekt undviks att interagera med det, eftersom det kan orsaka oförutsedda problem. När KKP fattade beslutet om att skriva om den här koden, hur inblandade var du i processen som fokuserade på den nya designen? Hur mycket övervakning ger du till projekt som Crimewatch för att se till att de uppfyller dina krav och att de inte lägger till tekniska skulder på vägen? Hur glad var du när grönlampan fick skriva om Crimewatch?
När det gäller den faktiska tekniska designen, inte mycket, och inte inblandad i speldesignen. Den tekniska ledningen för spellagslag (CCP Atlas) och i första hand seniorprogrammeraren (CCP Masterplan) i teamet som implementerade det nya systemet var människorna i grävningarna för det verkliga designarbetet. Min roll var att belysa det faktum att den gamla Crimewatch-koden var skör, försiktighetsprogrammerare och lag som vågade in i den koden och direkt övervakar sitt arbete, främja idén om att den bör refactored genom att demonstrera den kostnad som det aktuella systemet / koden orsakade oss , och ställa in standarder för implementering och prestanda testning (QA Director är ansvarig för funktionstester och allmänna testmetoder).
Jag var väldigt glad när projektet var slutligen grönbelysning. Det är alltid bra att kunna korsa dessa saker utanför listan och sedan gå vidare till nästa system.
Jag tycker att hela tekniska skuldsättningsläget är fascinerande av ditt jobb, särskilt eftersom det handlar om många gamla, centrala EVE-system som spelarna har svårt att arbeta med och / eller vill se refactored med bättre och modernare funktioner . KKP har varit noga med att ta itu med dessa områden av gammal, spröd kod.
Skulle företagets rollsystem falla in i den tekniska skuldstocken?
I viss utsträckning, men mestadels är det här systemet en fråga om vad den ska åstadkomma och därigenom eventuellt härleda en omarbetad speldesign. Koden för det systemet är inte särskilt dålig.
"Inte i dålig form", i vilken avseelse? Ur ett spelarperspektiv är rollsystemet svårt att arbeta med, och saker som folk skulle förvänta sig att göra, måste ofta utföras med olika udda lösningar. (Kelduum har dokumenterat några av dessa lösningar i hans kampar får företagens roller att verka på några grundläggande sätt.) Jag antar att koden kan vara i "bra form" med tanke på vad det egentligen var och inte var tänkt att göra. De flesta spelare skulle komma överens om att det behövs en översyn. Är det tillräckligt bra för en sådan översyn, om den gavs utvecklingsprioritering?
Jag använder "inte i dålig form" i samband med den tekniska skuldbacken från en rent teknisk aspekt. Vad du beskriver är användbarhetsproblem i systemet, vad jag kallade "en fråga om vad den ska åstadkomma och därigenom eventuellt härleda en omarbetad speldesign". Ur ett tekniskt perspektiv är själva koden inte så dålig, jämförbar läsbar i det stora systemet med saker och inte dåligt strukturerad.
Vad är några av de system som faller i den tekniska skuldstocken?
POS-systemet, webbläsaren i spel, prestandaförbättringar för uppstart av klienter, prestandaförbättringar för att skicka fysikimuleringshändelser till klienter, prestandaförbättringar och refactoring av attributsystemet. för att nämna några. Det finns andra system men de är antingen lågnivå eller internt verktyg eller pipeline. Några av dessa system faller in i flera andra kategorier; som POS-systemet har användbarhet och designaspekter, varav några vi tar upp i Odyssey med kvalitetsförbättringar.
Vem fattar det slutliga beslutet om vilka tekniska skulderstockar som ska hanteras?
I slutändan är det Senior Producent som gör ett samtal på vad eftersläpningen för varje release innehåller. Hon söker input från olika parter om prioriteringarna och försöker balansera de olika tekniska och affärsmässiga behoven. Objekt på den tekniska skuldstocken har olika storlekar och därför kan en mindre uppgift bli gjort tidigare (eftersom det passar in i schemat) även om det har mindre teknisk prioritet än en större uppgift. Där det kommer att bli väsentliga förändringar i spelmekaniken, som med Crimewatch, faller detta under ledningens speldesigner.
Ändå måste du fortfarande ha en rättvis insats på dessa prioriteringar. Jag skulle kunna tänka mig att den Senior Producenten måste förlita sig på din expertis och erfarenhet av den tekniska skuldstocken?
Att veta hur seniorproducenten behöver balansera de olika behoven så skickar jag inte henne en enda prioriterad lista. snarare diskuterar jag eftersläpningen med henne och den relativa betydelsen och möjliga storleken på varje projekt tillsammans med hur man gör vissa tekniska skulderbacklog-uppgifter kan möjliggöra andra saker för henne och hur man inte gör andra vissa tekniska skulderbacklog-uppgifter kan eventuellt "måla oss in i ett hörn ".
Är tekniska skulderstockar som hanteras av ett visst lag? Eller delas de ut till lag som bygger på vilka som bäst kan hantera dem (dvs teamkompetens)
De hanteras av alla lag, även om Team Gridlock har varit inblandad i endast tekniska skulderbacklog-uppgifter, vilket passar resten av sin eftersläpning och expertis.
Är tekniska skulderstockar hanterade på en expansionsbaserad basis, eller är de helt enkelt pågående och inte i allmänhet knutna till en viss expansionscykel?
Både.
Vilka tekniska skulderstockar har man tagit hand om för Odyssey-expansionen?
För att nämna några: Vi förbättrar patching (det har varit ett litet antal misslyckanden vid användning av HTTP / 1.0 proxies), omskrivning av generationsprocessen för bildexportsamling och omprövning av felhantering och loggning i EVE API samt installationsmetoden av API och uppdatera sin interna cachemekanism (lokal och distribuerad.)