Innhold
Dette er det andre av et trepartsintervju. Du kan les den første delen her.
***
Min forståelse for fleksibel utvikling er ganske grunnleggende. Jeg har aldri jobbet med metodikken, men har lest litt om det her og der. Hva er en teknisk gjeldsbacklog?
En backlog er en oppgaveliste; men det er en prioritert oppgaveliste som kan bli prioritert hver annen uke (på sprintgrenser) og lagene forplikter seg bare til et to-ukers vindu (en sprint). En tilbakebetaling av teknisk gjeld er en del av den generelle etterspørselen og historier (oppgaver) som er sammenflettet med den generelle etterspørselen.
Vel, det forteller meg ikke noe, men jeg gjorde en rask google, litt mer lesing, og har bestemt at "Teknisk gjeld er det som gjør kode vanskelig å jobbe med. Det er en usynlig morder av programvare, og må være aggressivt administrert. " Basert på det, tror jeg jeg forstår et aspekt av jobben mye bedre. Modernisering, oppfordring til standarder, noe av den eldre koden i EVE Online-kodebase, for eksempel hva som skjedde med Crimewatch i fjor.
Jeg vet at noen revolusjonering av den gamle bedriftens og POS-koden ikke er på utviklingsskifer når som helst snart, men hvor opptatt ville du være hvis noen sa "La oss omskrive dette og gjøre det riktig!"
Du kan kanskje huske diskusjonene som skjedde rundt POSes nylig; KKP Seagull håndterer kommunikasjon om det aktuelle emnet. Jeg kunne diskutere emnet for teknisk gjeld, men ikke i sammenheng med POSes.
Greit nok. La oss takle dette fra en annen retning. Crimewatch. Av alle kontoer er et gammelt, veldig skjøre stykke kode. Det var veldig vanskelig å jobbe med, og de fleste prosjekter unngikk å interagere med det, fordi det kunne føre til uforutsette problemer. Når KKP tok beslutningen om å omskrive denne koden, hvor involvert var du i prosessen som fokuserte på det nye designet? Hvor mye tilsyn gir du til prosjekter som Crimewatch for å sikre at de er i samsvar med dine standarder og at de ikke legger til teknisk gjeld nedover veien? Hvor glad var du da Greenlight ble gitt til å skrive om Crimewatch?
Når det gjelder den faktiske tekniske design, ikke mye, og ikke involvert i spilldesign. Teknisk ledelse for spillspillene (CCP Atlas) og først og fremst senior serverprogrammerer (CCP Masterplan) i teamet som implementerte det nye systemet, var folkene i grøftene for det aktuelle designarbeidet. Min rolle var å markere det faktum at den gamle Crimewatch-koden var sprø, forsiktighetsprogrammerere og lag som ventured inn i koden og direkte overvåker arbeidet deres, fremmer ideen om at den burde bli refactored ved å demonstrere kostnadene det nåværende system / kode forårsaket oss , og angi standarder for implementering og ytelsestesting (QA-direktøren er ansvarlig for funksjonstesting og generell testing).
Jeg var veldig glad da dette prosjektet endelig ble grønnlyset; Det er alltid godt å kunne krysse disse tingene ut av listen, og deretter gå videre til neste system.
Jeg finner hele teknisk gjeldsbacklog del av jobben fascinerende, spesielt siden det dreier seg om mange gamle, kjente EVE-systemer som spillerne har vansker med å jobbe med og / eller vil se refactored med bedre og mer moderne funksjoner . KKP har vært forsiktig med å takle disse områdene av gammel, sprø kode.
Ville bedriftens rolle system falle inn i den tekniske gjelden bagasjen?
I en viss grad, men det meste er systemet et spørsmål om hva den skal oppnå og derfra kan det oppstå en omarbeidet spilldesign. Koden for det systemet har ikke særlig dårlig form.
"Ikke i dårlig form", i hvilken henseende? Fra et spillerperspektiv er rollesystemet vanskelig å jobbe med, og ting som folk forventer det gjør, må ofte utføres med ulike utallige løsninger. (Kelduum har dokumentert noen av disse løsningene i sin kamp, få bedriftsrollene til å oppføre seg på noen grunnleggende måter.) Jeg antar at koden kunne være i "god form" gitt hva det egentlig var og ikke var laget for å gjøre. De fleste spillere vil være enige om at det er behov for en overhaling. Er det i god nok form for en slik overhaling, ble det gitt utviklingsprioritet?
Jeg bruker "ikke i dårlig form" i sammenheng med den tekniske gjeldsbacken fra et rent teknisk aspekt. Det du beskriver er brukbarhetsproblemer i systemet, det jeg refererte til som "et spørsmål om hva det skal oppnå og derfra muligens utlede en omarbeidet spilldesign". Fra et teknisk perspektiv er koden i seg selv ikke så ille, relativt lesbar i den store ordningen av ting og ikke dårlig strukturert.
Hva er noen av systemene som faller inn i gjeldsforpliktelsen?
POS-systemet, nettleseren i spillet, ytelsesforbedringer til oppstart av klient, ytelsesforbedringer for å sende fysikkimuleringshendelser til klienter, ytelsesforbedringer og refactoring av attributtsystemet; for å nevne noen. Det finnes andre systemer, men de er enten lavnivå eller internt verktøy eller rørledning. Noen av disse systemene faller inn i flere andre kategorier; slik som POS-systemet har brukervennlighet og designaspekter, hvorav noen adresserer oss i Odyssey med kvalitetsforbedringer.
Hvem tar den endelige avgjørelsen om hvilke tekniske gjeldsbegrensningsposter som skal håndteres?
Til syvende og sist er det seniorprodusenten som ringer på hva bagasjen for hver utgivelse inneholder. Hun søker innspill fra ulike partier om prioriteringene og forsøker å balansere ulike tekniske og forretningsbehov. Elementer på tilbakebetalingen for teknisk gjeld har ulike størrelser, og derfor kan en mindre oppgave bli gjort tidligere (fordi den passer inn i tidsplanen), selv om den har mindre teknisk prioritet enn en større oppgave. Hvor det vil bli vesentlige endringer i spillmekanikken, som med Crimewatch, faller dette under ledelsen av spillspilldesigneren.
Likevel må du fortsatt ha en god innsats på disse prioritetene. Jeg kan tenke meg at Seniorprodusenten må stole på din kompetanse og erfaring med den tekniske gjeldsbacken?
Å vite hvordan seniorprodusenten trenger å balansere de ulike behovene, så sender jeg ikke henne en enkelt prioritert liste; heller diskuterer jeg tilbakemeldingen med henne og den relative betydningen og mulige størrelsen til hvert prosjekt sammen med hvordan det å gjøre visse tekniske gjeldsoppgaver kan muliggjøre andre ting for henne og hvordan ikke å gjøre andre bestemte tekniske gjeldsoppgaver kan muligens "male oss inn i et hjørne ".
Er tekniske gjeldsbegrensningsposter håndtert av et bestemt lag? Eller deles de ut til lag basert på hvilke som best kan håndtere dem (dvs. lagkompetanse)
De håndteres av alle lagene, selv om Team Gridlock har vært involvert i kun teknisk gjeldsbacklogg, som passer til resten av sin etterspørsel og kompetanse.
Er tekniske tilbakebetalingsposter håndtert på utvidelsesbasis, eller fortsetter de bare, og er ikke vanligvis knyttet til en bestemt ekspansjons syklus?
Både.
Hvilke tekniske gjeldsbegrensningsposter ble taklet for Odyssey-utvidelsen?
For å nevne noen få: Vi forbedrer patching (det har vært et lite antall feil ved bruk av HTTP / 1.0 proxyer), omskrivning av generasjonsprosessen for Image Export Collection og omarbeiding av feilhåndtering og logging i EVE API, samt distribusjonsmetoden av API og oppdatering av sin interne caching-mekanisme (lokal og distribuert.)