Conţinut
Acesta este cel de-al doilea interviu în trei părți. Poti citiți prima parte aici.
***
Înțelegerea mea despre dezvoltarea agilă este destul de fundamentală. Nu am lucrat niciodată sub metodologie, dar am citit puțin despre asta aici și acolo. Ce anume este o întârziere a datoriei tehnice?
O întârziere este o listă de sarcini; dar este o listă de sarcini prioritizată care poate fi re-prioritizată la fiecare două săptămâni (la limitele sprintului), iar echipele se angajează doar pentru o fereastră de două săptămâni (un sprint). O întârziere a datoriei tehnice este o subsecțiune a întârzierilor globale și a povestilor (sarcinilor) care sunt intercalate cu întârzierile generale.
Ei bine, asta nu-mi spune o tonă, dar am făcut un google rapid, un pic mai mult de citit, și am stabilit că "Datoria tehnică este ceea ce face codul greu de a lucra cu. Este un ucigaș invizibil de software, și trebuie să fie agresiv gestionate. " Pe baza asta, cred că înțeleg mult mai bine un aspect al slujbei tale. Modernizarea, aducerea la standarde a unor coduri mai vechi din codul EVE Online, cum ar fi ceea ce sa întâmplat cu Crimewatch anul trecut.
Știu că orice revizuire a vechii coduri corporative și POS nu se află pe platforma dezvoltării în curând, dar cât de entuziasmat ar fi dacă cineva a spus "Să rescriem acest lucru și să facem cum trebuie!"
S-ar putea să vă amintiți recent discuțiile care au avut loc în jurul POS; CPP Pescărușul se ocupă de comunicarea cu privire la acest subiect. Aș putea discuta subiectul datoriei tehnice, dar nu în contextul POS.
Destul de corect. Să abordăm acest lucru dintr-o direcție diferită. Crimewatch. Prin toate conturile, o bucată de cod veche, foarte fragilă. A fost foarte dificil să lucrați și majoritatea proiectelor au evitat să interacționeze cu el, deoarece ar putea provoca probleme neprevăzute. Când PCC a luat decizia de a rescrie acest cod, cât de implicat ați fost în procesul care sa axat pe noul design? Cât de multă supraveghere acordați unor proiecte precum Crimewatch pentru a vă asigura că respectă standardele dvs. și că nu adaugă datoriilor tehnice pe drum? Cât de fericit ați fost când a fost dată lumina verde pentru a rescrie Crimewatch?
În ceea ce privește designul tehnic real, nu foarte mult, și nu sunt implicate în proiectarea jocului. Conducerea tehnică a echipelor de joc (PCC Atlas) și, în primul rând, programul de server senior (CCP Masterplan) în echipa care a implementat noul sistem au fost oamenii din tranșee pentru lucrările de proiectare reale. Rolul meu a fost acela de a sublinia faptul că vechiul cod Crimewatch era programator și programator prudent și prudenți care se îndrăgostiseră de codul respectiv și-și monitoriza direct activitatea, promova ideea că ar trebui să fie refactată demonstrând costul pe care l-a cauzat sistemul / codul actual , și a stabilit standardele pentru implementarea și testarea performanțelor (directorul QA este responsabil de testarea caracteristicilor și de practicile generale de testare).
Am fost foarte fericit când proiectul a fost în cele din urmă verde; este întotdeauna bine să poți trece aceste lucruri de pe listă și apoi să treci la următorul sistem.
Am descoperit întreaga parte a sarcinilor tehnice datorate întârzierii, mai ales că se învârte în jurul multor sisteme vechi, de bază EVE pe care jucătorii le găsesc dificil de a lucra și / sau ar dori să le vadă refactate cu caracteristici mai bune și mai moderne . PCC a fost atentă în abordarea acestor zone de cod vechi, fragil.
Sistemul de rol corporativ ar intra în Backupul datoriei tehnice?
Într-o anumită măsură, dar mai ales acel sistem este o chestiune a ceea ce ar trebui să realizeze și de acolo poate deriva un design de joc revizuit. Codul pentru acest sistem nu este într-o formă deosebit de proastă.
"Nu în formă rea", în ce sens? Din perspectiva unui jucător, sistemul de rol este dificil de a lucra și lucrurile pe care oamenii ar aștepta să le facă, de multe ori trebuie să fie realizate cu diverse soluții ciudate. (Kelduum a documentat câteva dintre aceste soluții în luptele sale, prin care rolurile corporației se comportă în unele moduri de bază.) Presupun că codul ar putea fi "în formă bună", având în vedere ceea ce a fost și nu a fost conceput să facă. Majoritatea jucătorilor ar fi de acord că are nevoie de o revizie. Este într-o formă suficient de bună pentru o astfel de revizie, dacă ar fi dat prioritate dezvoltării?
Folosesc "nu într-o formă proastă" în contextul Deblării tehnice a datoriilor dintr-un aspect pur tehnic. Ceea ce descrieți sunt aspectele de uzabilitate ale sistemului, ceea ce am denumit "o întrebare a ceea ce ar trebui să realizeze și de unde rezultă un proiect de joc revizuit". Din punct de vedere tehnic, codul în sine nu este atât de rău, încât poate fi citit comparativ în marea schemă a lucrurilor și nu este structurat prost.
Care sunt câteva dintre sistemele care intră în Backdownul datoriei tehnice?
Sistemul POS, browserul în joc, îmbunătățiri ale performanței la pornirea clientului, îmbunătățiri ale performanței pentru a expedia evenimentele de simulare a fizicii către clienți, îmbunătățirea performanțelor și refactorizarea sistemului de atribute; a numi câteva. Există și alte sisteme, dar acestea sunt instrumente sau conducte de nivel inferior sau interne. Unele dintre aceste sisteme de mai sus se încadrează în mai multe alte categorii; cum ar fi sistemul POS, are aspecte de utilizare și design, dintre care unele se adresează în Odyssey cu îmbunătățirea calității vieții.
Cine face decizia finală cu privire la elementele de întârziere a datoriei tehnice?
În cele din urmă, Producătorul Senior face un apel asupra a ceea ce conține restanțele pentru fiecare versiune. Ea caută contribuții din partea diferitelor părți cu privire la priorități și încearcă să echilibreze diferitele nevoi tehnice și de afaceri. Elementele din backlogul datoriei tehnice sunt de diferite mărimi și, prin urmare, o sarcină mai mică poate fi făcută mai devreme (deoarece se încadrează în program), chiar dacă are o prioritate mai mică decât o sarcină mai mare. În cazul în care vor exista schimbări semnificative în mecanica de joc, cum ar fi cu Crimewatch, aceasta intră în sfera de competență a designerului jocului de plumb.
Chiar și așa, trebuie să mai aveți o contribuție corectă la aceste priorități. Mi-aș imagina că producătorul senior trebuie să se bazeze pe expertiza și experiența dvs. cu Deblocarea tehnică a datoriilor?
Cunoscând modul în care producătorul senior trebuie să echilibreze diferitele nevoi, atunci nu îi trimit o singură listă prioritară; mai degrabă discut despre întârzierea cu ea și importanța relativă și mărimea posibilă a fiecărui proiect împreună cu modul în care efectuarea anumitor sarcini tehnice de întârziere a datoriilor poate permite alte lucruri pentru ea și cum să nu faci alte sarcini tehnice de întârziere a datoriilor ar putea să ne "picteze într-un colț “.
Sunt elementele tehnice de întârziere a datoriei tehnice gestionate de o anumită echipă? Sau sunt predate echipelor pe baza cărora se pot descurca cel mai bine (de ex. Expertiza echipei)
Acestea sunt tratate de către toate echipele, deși echipa Gridlock a fost implicată numai în sarcini tehnice legate de datoriile de întârziere, care se potrivesc restului de întârziere și expertiză.
Elementele de întârziere a datoriei tehnice sunt abordate pe baza unei expansiuni cu extindere, sau sunt pur și simplu în curs de desfășurare și nu sunt în general legate de un anumit ciclu de extindere?
Ambii.
Ce elemente de întârziere a datoriei tehnice au fost abordate pentru expansiunea Odyssey?
Pentru a numi câteva: Îmbunătățim patch-urile (a existat un număr redus de erori atunci când se utilizează HTTP / 1.0 proxy-uri), rescrierea procesului de generare a colecției Image Export și modificarea erorilor și gestionarea erorilor în EVE API, precum și metoda de implementare a API și actualizarea mecanismului său intern de memorare în cache (local și distribuit).