Contenuto
Questa è la seconda di un'intervista in tre parti. Puoi leggi la prima parte qui.
***
La mia comprensione dello sviluppo agile è piuttosto basilare. Non ho mai lavorato sotto la metodologia, ma ne ho letto un po 'qua e là. Che cos'è esattamente un arretrato del debito tecnico?
Un backlog è un elenco di attività; ma è una lista di compiti con priorità che può essere riordinata ogni due settimane (sui confini dello sprint) e le squadre si impegnano solo per una finestra di due settimane (uno sprint). Un backlog del debito tecnico è una sottosezione del backlog e delle storie (attività) complessive che sono intercalate con il backlog generale.
Beh, questo non mi dice una tonnellata, ma ho fatto un rapido google, un po 'più di lettura, e ho determinato che "il debito tecnico è ciò che rende il codice difficile da lavorare. È un killer invisibile di software, e deve essere gestito in modo aggressivo. " Sulla base di ciò, credo di capire molto meglio un aspetto del tuo lavoro. Modernizzando, portando agli standard, parte del codice più vecchio nella base di codice EVE Online, come quello che è successo a Crimewatch l'anno scorso.
So che qualsiasi revamping del vecchio codice aziendale e POS non è nella lista di sviluppo in qualunque momento, ma quanto sarebbe felice se qualcuno dicesse "Riscriviamo questo e rendilo giusto!"
Potresti ricordare le discussioni che sono state fatte recentemente sui POS; CCP Seagull gestisce la comunicazione su questo argomento. Potrei discutere l'argomento del debito tecnico ma non nel contesto dei POS.
Giusto. Affrontiamo questo da una direzione diversa. Crimewatch. A conti fatti un vecchio codice molto fragile. È stato molto difficile lavorare con e la maggior parte dei progetti ha evitato di interagire con esso, perché potrebbe causare problemi imprevisti. Quando CCP ha preso la decisione di riscrivere questo codice, in che modo era coinvolto il processo incentrato sul nuovo design? Quanta supervisione offri a progetti come Crimewatch per assicurarti che siano all'altezza dei tuoi standard e che non aumentino il debito tecnico lungo la strada? Quanto sei felice quando è stato dato il riserbo per riscrivere Crimewatch?
In termini di progettazione tecnica effettiva, non molto, e non coinvolti nel design del gioco. La guida tecnica per i team di gioco (CCP Atlas) e principalmente il programmatore di server senior (CCP Masterplan) nel team che ha implementato il nuovo sistema sono state le persone nelle trincee per il lavoro di progettazione reale. Il mio ruolo era quello di evidenziare il fatto che il vecchio codice di Crimewatch era programmatori e team di cautela, che si avventuravano in quel codice e monitoravano direttamente il loro lavoro, promuovendo l'idea di dover essere refactored dimostrando il costo che il sistema / codice attuale ci stava causando e stabilire gli standard per l'implementazione e il test delle prestazioni (il responsabile della qualità è responsabile per le prove di funzionalità e le pratiche di test generali).
Sono stato molto felice quando questo progetto è stato finalmente messo in luce; è sempre bene essere in grado di cancellare queste cose dall'elenco e quindi passare al sistema successivo.
Sto trovando affascinante l'intero arretrato del debito tecnico del tuo lavoro, specialmente perché ruota attorno a molti vecchi sistemi EVE di base che i giocatori trovano difficili da lavorare e / o vorrebbero vedere rifattorizzati con caratteristiche migliori e più moderne . Il PCC è stato cauto nell'affrontare queste aree di codice vecchio e fragile.
Il sistema dei ruoli aziendali potrebbe rientrare nel backlog del debito tecnico?
In una certa misura, ma soprattutto quel sistema è una questione di ciò che dovrebbe portare a termine e da lì può derivare un progetto di gioco revisionato. Il codice per quel sistema non è particolarmente cattivo.
"Non in cattive condizioni", sotto quale aspetto? Dal punto di vista del giocatore, il sistema dei ruoli è difficile da lavorare, e le cose che le persone si aspetterebbero che facciano, spesso devono essere eseguite con vari metodi alternativi. (Kelduum ha documentato alcuni di questi metodi alternativi nelle sue lotte per far sì che i ruoli aziendali si comportino in alcuni modi basilari.) Suppongo che il codice potrebbe essere in "buona forma" dato quello che era in realtà e non era progettato per farlo. La maggior parte dei giocatori concorda sul fatto che ha bisogno di una revisione. E 'in forma abbastanza buona per una tale revisione, se fosse data priorità allo sviluppo?
Sto usando "non in cattive condizioni" nel contesto del Technical Debt Backlog da un aspetto puramente tecnico. Quello che stai descrivendo sono problemi di usabilità nel sistema, quello che ho definito "una domanda su cosa si suppone debba portare a termine e da lì probabilmente derivare un progetto di gioco revisionato". Da un punto di vista tecnico, quindi, il codice in sé non è così male, relativamente leggibile nel grande schema delle cose e non strutturato male.
Quali sono alcuni dei sistemi che rientrano nel backlog del debito tecnico?
Il sistema POS, il browser in-game, miglioramenti delle prestazioni all'avvio del client, miglioramenti delle prestazioni per la distribuzione di eventi di simulazione fisica ai clienti, miglioramenti delle prestazioni e refactoring del sistema di attributi; per dirne alcuni. Esistono altri sistemi, ma sono strumenti o pipeline di basso livello o interni. Alcuni di questi sistemi sopra rientrano in più altre categorie; come il sistema POS ha aspetti di usabilità e design, alcuni dei quali stiamo affrontando in Odyssey con il miglioramento della qualità della vita.
Chi prende la decisione finale su quali elementi del Backlog del debito tecnico verranno affrontati?
In definitiva è il produttore senior che effettua una chiamata su ciò che contiene il backlog per ogni versione. Cerca input da varie parti sulle priorità e cerca di bilanciare le varie esigenze tecniche e commerciali. Gli articoli nel backlog del debito tecnico sono di varie dimensioni e pertanto un'attività più piccola può essere eseguita in precedenza (perché si adatta alla pianificazione) anche se ha una priorità tecnica minore rispetto a un'attività più grande. Dove ci saranno cambiamenti significativi nelle meccaniche di gioco, come con Crimewatch, questo rientra nella sfera di competenza del progettista di giochi di piombo.
Anche così, devi comunque avere un bel po 'di input su quelle priorità. Immagino che il Senior Producer debba fare affidamento sulla tua esperienza ed esperienza con il Technical Debt Backlog?
Sapendo come il Senior Producer deve bilanciare le diverse esigenze, allora non le mando un unico elenco prioritario; piuttosto discuto l'arretrato con lei e l'importanza relativa e la dimensione possibile di ogni progetto insieme a come certe attività di recupero del debito tecnico possono abilitare altre cose per lei e in che modo non svolgere altre determinate operazioni di recupero del debito tecnico possono "dipingerci in un angolo" ".
Gli articoli del Backlog del debito tecnico sono gestiti da un particolare team? Oppure vengono distribuiti ai team in base ai quali è possibile gestirli al meglio (ad esempio, l'esperienza del team)
Sono gestiti da tutti i team, sebbene Team Gridlock sia stato coinvolto solo in compiti di Technical Debt Backlog, come si adatta al resto del loro backlog e competenza.
Le voci del Technical Debt Backlog sono affrontate in base all'espansione per espansione o sono semplicemente in corso e generalmente non legate a un ciclo di espansione specifico?
Tutti e due.
Quali elementi del Backlog del debito tecnico sono stati affrontati per l'espansione Odyssey?
Per citarne alcuni: Stiamo migliorando le patching (c'è stato un basso numero di errori quando si usano i proxy HTTP / 1.0), riscrivendo il processo di generazione di Image Export Collection, e revampando la gestione degli errori e la registrazione nell'API EVE e il metodo di implementazione dell'API e l'aggiornamento del suo meccanismo di caching interno (locale e distribuito).