Obsah
Toto je druhý pohovor z troch častí. Môžeš Prečítajte si prvú časť tu.
***
Moje chápanie agilného vývoja je pomerne základné. Nikdy som nepracoval podľa metodiky, ale čítal som o tom trochu tu a tam. Čo presne je technický dlh?
Nevyžiadaná pošta je zoznam úloh; ale je to zoznam úloh s prioritou, ktorý sa môže každé dva týždne znovu nastaviť na priority (na hraniciach sprintu) a tímy sa zaviažu iba na dvojtýždňové okno (jeden sprint). Nevyhnutný technický dlh je podkapitola celkového počtu nevybavených prípadov a príbehov (úloh), ktoré sú preložené všeobecným oneskorením.
No, to mi nehovorí tonu, ale urobil som rýchle google, trochu viac čítania, a zistili sme, že "Technický dlh je to, čo robí kód ťažký na prácu. Je to neviditeľný vrah softvéru a musí byť agresívne riadené. “ Na základe toho verím, že lepšie chápem jeden aspekt vašej práce. Modernizácia, prispôsobenie sa štandardom, niektoré zo starších kódov v databáze EVE Online, ako napríklad to, čo sa stalo Crimewatch minulý rok.
Viem, že akékoľvek prebudenie starého firemného a POS kódu nie je na vývoji bridlice kedykoľvek čoskoro, ale ako vzrušený by ste boli, keby niekto povedal: „Prepíšme to a spravme to správne!“
Môžete si spomenúť na diskusiu, ktorá sa stala okolo POSES nedávno; CCP Seagull zvláda komunikáciu na túto tému. Mohol by som diskutovať o predmete technického dlhu, ale nie v kontexte POS.
Dostatočne dosť. Riešme to z iného smeru. Crimewatch. Podľa všetkého je to starý, veľmi krehký kúsok kódu. Spolupráca s ním bola veľmi ťažká a väčšina projektov sa s ňou vyhýbala, pretože by to mohlo spôsobiť nepredvídané problémy. Keď sa CCP rozhodla prepísať tento kód, ako ste sa zapojili do procesu zameraného na nový dizajn? Do akej miery dohliadate na projekty, ako je Crimewatch, aby ste sa uistili, že sú v súlade s vašimi štandardmi a že nepridávajú technický dlh po ceste? Ako ste boli šťastní, keď ste dostali zelenú na prepísanie Crimewatch?
Pokiaľ ide o skutočný technický dizajn, nie veľa, a nie je zapojený do herného dizajnu. Technický náskok pre tímy hrania hier (CCP Atlas) a predovšetkým senior serverový programátor (CCP Masterplan) v tíme, ktorý implementoval nový systém, boli ľudia v zákopoch pre skutočnú projekčnú prácu. Mojou úlohou bolo zdôrazniť skutočnosť, že starý kód Crimewatch bol krehký, programátori opatrnosti a tímy, ktoré sa pustili do tohto kódu a priamo monitorovali svoju prácu, propagovali myšlienku, že by mal byť refaktorovaný demonštrovaním nákladov, ktoré nám súčasný systém / kód spôsoboval a stanoviť štandardy pre implementáciu a testovanie výkonnosti (riaditeľ oddelenia kvality je zodpovedný za testovanie funkcií a všeobecné testovacie postupy).
Bol som veľmi šťastný, keď bol tento projekt konečne greenlighted; je vždy dobré byť schopný tieto veci vynechať zo zoznamu a potom prejsť na ďalší systém.
Zistil som, že celý technický dlh backlog časť vašej práce fascinujúce, najmä preto, že sa točí okolo mnohých starých, jadrových systémov EVE, že hráči nájsť ťažké pracovať a / alebo by chcel vidieť refactored s lepšími, modernejšie funkcie , ČKS bola opatrná pri riešení týchto oblastí starého, krehkého kódu.
Mal by systém podnikovej úlohy spadať do Technického dlhu?
Do určitej miery, ale väčšinou tento systém je otázkou toho, čo má dosiahnuť, a odtiaľ možno odvodiť prepracovaný herný dizajn. Kód pre tento systém nie je obzvlášť zlý.
"Nie je v zlom stave," v akom ohľade? Z pohľadu hráča je ťažké pracovať so systémom rolí a veci, ktoré by ľudia očakávali, musia byť často vykonávané s rôznymi podivnými riešeniami. (Kelduum zdokumentoval niekoľko z týchto riešení v jeho bojoch, aby sa podnikové role správali v niektorých základných smeroch.) Predpokladám, že kód by mohol byť v „dobrom stave“ vzhľadom na to, čo to vlastne bolo a nebol navrhnutý. Väčšina hráčov by súhlasila s tým, že je potrebné vykonať revíziu. Je pre takúto generálnu opravu v dobrej forme, ak má prioritu rozvoja?
Využívam „nie je v zlom stave“ v kontexte technickej nedokonalosti dlhu z čisto technického hľadiska. To, čo opisujete, sú otázky použiteľnosti v systéme, čo som označil ako „otázka, čo má dosiahnuť a odtiaľ možno odvodiť prepracovaný herný dizajn“. Z technického hľadiska nie je samotný kódex taký zlý, porovnateľne čitateľný vo veľkej schéme vecí a nie je zle štruktúrovaný.
Aké sú niektoré systémy, ktoré spadajú do Technického dlhu?
POS systém, prehliadač hier, vylepšenia výkonu pri spúšťaní klienta, vylepšenia výkonu na simuláciu udalostí fyziky klientom, vylepšenia výkonu a refaktorovanie systému atribútov; vymenovať zopár. Existujú aj iné systémy, ale sú to buď nízkoúrovňové alebo vnútorné nástroje alebo potrubia. Niektoré z týchto systémov spadajú do viacerých iných kategórií; napríklad POS systém má použiteľnosť a dizajnové aspekty, z ktorých niektoré riešime v Odyssey s vylepšeniami kvality života.
Kto urobí konečné rozhodnutie o tom, čo sa bude riešiť s technickými položkami Backlogu?
Nakoniec je to Senior Producer, ktorý zavolá na to, čo obsahuje backlog pre každé vydanie. Hľadá podnety od rôznych strán o prioritách a snaží sa vyvážiť rôzne technické a obchodné potreby. Položky v technickom zadlžení sú rôznej veľkosti, a preto môže byť menšia úloha vykonaná skôr (pretože zapadá do harmonogramu), aj keď má menej technickej priority ako väčšia úloha. Tam, kde dôjde k významným zmenám v mechanike hry, ako je napríklad Crimewatch, to spadá do pôsobnosti hlavného herného dizajnéra.
Napriek tomu musíte mať k týmto prioritám dostatočný vstup. Chcel by som si predstaviť, že Senior Producer sa musí spoliehať na vaše odborné znalosti a skúsenosti s Technickým dlhovým Backlogom?
Vediac, ako potrebuje Senior Producer vyvažovať rôzne potreby, potom jej neodosielam jediný zoznam priorít; skôr som diskutovať o nevybavených s ňou a relatívna dôležitosť a možná veľkosť každého projektu spolu s tým, ako robiť určité technické zadlženie úlohy môže umožniť iné veci pre ňu a ako nerobiť ďalšie určité technické zadlženie úloh môže prípadne "maľovať nás do rohu ".
Spracúvajú položky technického debetu Backlog konkrétny tím? Alebo sú rozdané tímom, na základe ktorých sa s nimi dá najlepšie poradiť (t. J. Tímová expertíza)
Spracovávajú ich všetky tímy, aj keď tím Gridlock sa podieľal len na úlohách technického technického zadlženia.
Sú položky technického dlhu riešené na báze expanzie podľa expanzie, alebo sú jednoducho prebiehajúce a vo všeobecnosti nie sú viazané na konkrétny cyklus rozšírenia?
Both.
Aké položky technického dlhu boli vyriešené pre rozšírenie Odyssey?
Aby sme vymenovali aspoň niektoré: Zlepšujeme patching (pri použití proxy proxy HTTP / 1.0 došlo k malému počtu zlyhaní), prepisovali sme proces generovania Image Export Collection a vylepšili sme spracovanie chýb a protokolovanie v EVE API, ako aj metódu nasadenia a aktualizáciu interného mechanizmu ukladania do pamäte cache (lokálne a distribuované).