Tartalom
Ez a második rész egy három részből álló interjúból. tudsz olvassa el az első részt itt.
***
Az agilis fejlesztés megértése meglehetősen alapos. Soha nem dolgoztam a módszer szerint, de olvastam egy kicsit erről és ott. Pontosan mi a technikai adóssághiány?
A lemaradás feladatlista; de ez egy prioritást élvező feladatlista, amely kéthetente ismételten prioritást kaphat (sprinthatárokon), és a csapatok csak egy két hetes ablakot (egy sprint) vállalnak. A technikai adósság-elmaradás az általános lemaradás és a történetek (feladatok) alszakaszát képezi, amelyek az általános hátralékokkal párosulnak.
Nos, ez nem mond nekem egy tonnát, de egy gyors google-t, egy kicsit többet olvasok, és meghatároztam, hogy "a technikai adósság az, ami nehezen működik a kóddal. Ez egy szoftver láthatatlan gyilkosa, és agresszíven kezelték. " Ennek alapján úgy gondolom, hogy jobban megértem a munkád egyik szempontját. Az EVE Online kódbázisban a régebbi kódok modernizálása, szabványok felállítása, például a tavalyi Crimewatch-hez történt.
Tudom, hogy a régi vállalati és POS-kódok bármilyen átalakítása hamarosan nem a fejlesztési palánkon található, de mennyire izgatott lenne, ha valaki azt mondaná: „Tegyük át ezt, és tegyük helyesen!”
Emlékeztethetünk a közelmúltban a POSes-ekkel kapcsolatos megbeszélésekre; A CCP Seagull kezeli a kommunikációt ezen a területen. Megbeszélhetném a technikai adósság tárgyát, de nem a POSes-ek összefüggésében.
Elfogadható. Vegyük ezt más irányból. Crimewatch. Egyáltalán egy régi, nagyon törékeny kódrészlet. Nagyon nehéz volt dolgozni, és a legtöbb projekt elkerülte az interakciót, mert előre nem látható problémákat okozhat. Amikor a központi szerződő fél úgy döntött, hogy átírja ezt a kódot, mennyire volt benne az új designra összpontosító folyamat? Mennyi felügyeletet ad olyan projekteknek, mint a Crimewatch annak biztosítása érdekében, hogy azok megfeleljenek a szabványoknak, és hogy ne adjanak hozzá a technikai adóssághoz az úton? Milyen boldog voltál, amikor a zöldfényt átadták a Crimewatch átírásához?
A tényleges műszaki tervezés szempontjából nem sok, és nem vesz részt a játéktervezésben. A játékvezető csapatok (CCP Atlas) és elsődlegesen a vezető kiszolgáló programozó (CCP Masterplan) technikai vezetője az új rendszert megvalósító csapatban a tényleges tervezési munkákhoz tartozó emberek voltak. A szerepem az volt, hogy kiemeljem, hogy a régi Crimewatch kód törékeny volt, óvatosan programozói és csapatok, akik beleszóltak a kódba, és közvetlenül figyelemmel kísérik a munkájukat, előmozdítják azt az elképzelést, hogy a jelenlegi rendszer / kód által okozott költségeket igazolni kell. és állítsa be a végrehajtási és teljesítményvizsgálati szabványokat (a minőségbiztosítási igazgató felelős a jellemzők teszteléséért és az általános tesztelési gyakorlatokért).
Nagyon boldog voltam, amikor ez a projekt végül zölden megvilágított; mindig jó, ha képesek vagyunk átkelni ezeket a dolgokat a listáról, majd lépni a következő rendszerre.
A munkám egész technikai adósságának elmaradását lenyűgözőnek találom, különösen azért, mert sok régi, alapvető EVE rendszer körül forog, amelyeket a játékosok nehezen tudnak dolgozni, és / vagy jobb, modernebb funkciókat szeretne látni. . A KKP óvatosan kezelte ezeket a régi, törékeny kódokat.
A vállalati szerepkör-rendszer a technikai adósság-visszafizetésbe kerül?
Bizonyos mértékig, de többnyire ez a rendszer kérdése, hogy mit kell elérnie, és onnan talán átdolgozott játéktervezést eredményez. A rendszer kódja nem különösen rossz alak.
- Nem rossz alakban? A játékosok szemszögéből nehezen kezelhető a szereprendszer, és a dolgokat, amelyeket az emberek elvárnak, gyakran különböző furcsa megoldásokkal kell végrehajtani. (Kelduum néhány ilyen megoldást dokumentált a harcaiban, hogy a vállalati szerepek bizonyos alapvető módokon viselkedjenek.) Feltételezem, hogy a kód "jó formában" lehetne, mivel valójában nem volt és nem volt célja. A legtöbb játékos egyetértett abban, hogy szükség van egy nagyjavításra. Elég jó formában van-e ilyen átalakításra, ha fejlesztési prioritás lenne?
A „nem rossz alakot” használok a technikai adósság-visszafizetés keretében tisztán technikai szempontból. Amiről leírsz, a rendszer használhatósági problémái, amit neveztek „arra a kérdésre, hogy mit kell elérni, és onnan esetleg felülmúlhatatlan játéktervezést eredményeznek”. Műszaki szempontból maga a kód nem olyan rossz, viszonylag olvasható a dolgok nagy sémájában, és nem rosszul strukturált.
Melyek azok a rendszerek, amelyek a technikai adósság-visszafizetéshez tartoznak?
A POS rendszer, a játékon belüli böngésző, az ügyfélindítás teljesítményének javítása, a fizikai szimulációs események ügyfelek részére történő továbbításának teljesítményjavítása, a teljesítmény javítása és az attribútumrendszer refaktorozása; hogy csak néhányat említsünk. Vannak más rendszerek, de ezek alacsony szintű vagy belső eszközök vagy csővezetékek. A fenti rendszerek némelyike több más kategóriába is tartozik; mint például a POS-rendszer használhatósági és tervezési szempontok, amelyek közül néhányat az Odyssey-nél az életminőség javításával foglalkozunk.
Ki dönti el a végső döntést arról, hogy milyen technikai adóssághiány-elemeket fognak kezelni?
Végső soron ez az idősebb termelő, aki felhívja az egyes kiadások lemaradását. Különböző felek részéről érdeklődik a prioritásokról, és megpróbálja kiegyensúlyozni a különböző technikai és üzleti igényeket. A Technikai Adósság-visszavonás tételei különböző méretűek, ezért egy kisebb feladat előbbre kerülhet (mivel illeszkedik a menetrendbe), még akkor is, ha kevesebb technikai prioritás van, mint egy nagyobb feladat. Ahol jelentős változások következnek be a játékszerkezetekben, mint például a Crimewatch, ez a vezető játéktervező hatáskörébe tartozik.
Ennek ellenére még mindig tisztességesnek kell lennie a prioritásoknak. Elképzelném, hogy a Senior Producernek támaszkodnia kell a technikai adósság-visszafizetéssel kapcsolatos szakértelmére és tapasztalatára?
Tudván, hogy a Senior Producernek ki kell egyensúlyoznia a különböző igényeket, akkor nem küldök neki egyetlen prioritási listát; inkább a vele kapcsolatos lemaradást és az egyes projektek viszonylagos jelentőségét és lehetséges méretét tárgyalom, valamint azt, hogy bizonyos technikai adósság-visszafizetési feladatok hogyan tehetnek más dolgokat neki, és hogyan lehet, hogy más technikai adósság-visszafizetési feladatok nem teszik „egy sarokba ”.
Műszaki adósság-elmaradási tételeket kezel egy adott csapat? Vagy osztják ki azokat a csapatoknak, amelyek alapján a legjobban kezelhetik őket (azaz a csapat szakértelme)
Ezeket az összes csapat kezeli, bár a Gridlock csapata csak a technikai adósság-visszafizetési feladatokban vett részt, mivel a többi hátránya és szakértelme is megfelel.
Vajon a technikai adósság-elmaradás elemeket bővítési-bővítési alapon kezelik, vagy egyszerűen csak folyamatban vannak, és általában nem kötődnek egy adott bővítési ciklushoz?
Mindkét.
Milyen technikai adóssághiány-elemeket kezeltek az Odyssey bővítéshez?
Néhány név megnevezése: Javítjuk a javítást (a HTTP / 1.0 proxyk használatakor kis számú hiba történt), az Image Export Collection generálási folyamat átírása és a hibakezelés és az EVE API-ban való bejelentkezés, valamint a telepítési módszer megújítása az API és a belső gyorsítótár-mechanizmus (helyi és elosztott) frissítése.