Съдържание
Това е второто интервю от три части. Можеш прочетете първата част тук.
***
Моето разбиране за гъвкавото развитие е доста основно. Никога не съм работил по методологията, но съм прочел малко за него тук и там. Какво точно е техническото изоставане в дълга?
Закъснението е списък със задачи; но това е списък с приоритетни задачи, който може да се преориентира на всеки две седмици (по границите на спринта) и екипите се ангажират само за двуседмичен прозорец (един спринт). Техническият недостиг на дълг е подраздел на цялостното изоставане и истории (задачи), които се преплитат с общото изоставане.
Е, това не ми казва тон, но направих един бърз google, малко повече четене, и определих, че "Техническия дълг е това, което прави кода трудно за работа. Той е невидим убиец на софтуер и трябва да бъде агресивно управлявани. " Въз основа на това вярвам, че разбирам един аспект от вашата работа много по-добре. Модернизиране, довеждане до стандарти, някои от по-старите кодове в кодовата база EVE Online, като например това, което се случи с Crimewatch миналата година.
Знам, че всяко обновяване на стария корпоративен и ПОС код не е в скоро време, но колко ще бъдете възбудени, ако някой каже: "Нека го пренапишем и го направим правилно!"
Може да си спомните за дискусиите, които се случиха около POSes наскоро; CCP Seagull се занимава с комуникацията по този въпрос. Бих могъл да обсъдя темата за техническия дълг, но не и в контекста на POSes.
Достатъчно честно. Нека се справим с това от друга посока. Crimewatch. По всичко личи един стар, много крехък код. Беше много трудно да се работи, а повечето проекти избягваха да взаимодействат с нея, защото това може да доведе до непредвидени проблеми. Когато ККП взе решение да пренапише този код, как сте участвали в процеса, който се фокусира върху новия дизайн? Колко наблюдение давате на проекти като Crimewatch, за да се гарантира, че те отговарят на вашите стандарти и че те не добавят към техническия дълг по пътя? Колко сте щастливи, когато е дадена зелена светлина за пренаписване на Crimewatch?
По отношение на действителния технически дизайн, не много, а не участва в дизайна на играта. Техническото ръководство на екипите за игра (CCP Atlas) и предимно старшия сървър-програмист (CCP Masterplan) в екипа, който внедрява новата система, бяха хората в окопите за реалното проектиране. Моята роля беше да подчертая факта, че старият код на Crimewatch беше крехък, предпазлив програмист и екипи, които се впускат в този код и пряко наблюдават работата им, популяризират идеята, че трябва да се рефакторира като демонстрира разходите, които настоящата система / код ни причинява. и да определи стандартите за изпълнение и тестване на производителността (директорът по качеството отговаря за тестването на обекти и общите практики за тестване).
Бях много щастлив, когато този проект най-накрая беше осветен; винаги е добре да можеш да пресечеш тези неща от списъка и да преминем към следващата система.
Смятам, че цялата техническа задлъжнялост на вашата работа е очарователна, особено след като тя се върти около много стари, основни EVE системи, с които играчите срещат трудност да работят и / или биха искали да видят рефакторите с по-добри, по-модерни функции , ККП внимателно се занимаваше с тези стари, крехки кодове.
Дали корпоративната система на ролята попадне в техническия дълг на дълга?
До известна степен, но най-вече тази система е въпрос на това, което той трябва да постигне и оттам може да извлече основен дизайн на играта. Кодът на тази система не е в особено лоша форма.
- Не е в лоша форма - в какво отношение? От гледна точка на играча, системата за ролята е трудна за работа и нещата, които хората биха очаквали, често трябва да се извършват с различни странни заобикаляния. (Келдуум е документирал някои от тези заобикалящи решения в борбата си да накара корпоративните роли да се държат по някои основни начини.) Предполагам, че кодът може да бъде в "добра форма", като се има предвид това, което всъщност е било и не е предназначено да прави. Повечето играчи биха се съгласили, че се нуждаят от основен ремонт. Дали е в достатъчно добра форма за подобна реконструкция, дали е била дадена приоритет за развитие?
Използвам „не в лоша форма“ в контекста на техническия дълг на техническия дълг от чисто технически аспект. Това, което описвате, са проблемите на използваемостта в системата, което аз наричам „въпрос на това, което той трябва да постигне и оттам може да извлече основен дизайн на играта“. От техническа гледна точка самият код не е толкова лош, сравнително четлив в голямата схема на нещата и не е зле структуриран.
Какви са някои от системите, които попадат в техническия дълг на дълга?
POS системата, браузърът по време на игра, подобренията на производителността при стартиране на клиента, подобренията на производителността при диспечиране на физически симулационни събития на клиентите, подобрения в производителността и рефакторинг на атрибутивната система; за да назовем само няколко. Има и други системи, но те са или ниско ниво, или вътрешни инструменти или тръбопровод. Някои от тези системи по-горе попадат в множество други категории; като POS системата има аспекти на използваемостта и дизайна, някои от които ние разглеждаме в Odyssey с подобряване на качеството на живот.
Кой взема окончателното решение за това, какви ще бъдат решени елементите на техническия дълг?
В крайна сметка това е Старшият производител, който се обажда на съдържанието на закъснението за всяко издание. Тя търси принос от различни партии за приоритетите и се опитва да балансира различните технически и бизнес нужди. Елементите от техническия дълг на дълговете са с различни размери и затова по-малка задача може да се направи по-рано (защото се вписва в графика), дори ако има по-малко технически приоритет от по-голяма задача. Там, където ще има значителни промени в механиката на играта, като например с Crimewatch, това попада в обхвата на водещия дизайнер на игри.
Дори и така, все още трябва да имате доста принос за тези приоритети. Предполагам, че старшият производител трябва да разчита на вашия опит и опит с техническия дълг на дълговете?
Знаейки как старшият производител трябва да балансира различните нужди, аз не й изпращам един приоритетен списък; по-скоро обсъждам натрупването с нея и относителната важност и възможния размер на всеки проект, заедно с това как някои задачи по техническото неизпълнение на техническите задължения могат да позволят други неща за нея и как да не се изпълняват други задачи, свързани с техническия дълг на дълговете, които да ни "начертаят в ъгъла ".
Дали техническите дебитни задължения се обработват от конкретен екип? Или те се раздават на екипи, на базата на които най-добре могат да се справят с тях (напр. Екипни познания)
Те се обработват от всички отбори, въпреки че Team Gridlock е участвал само в задачи по Техническото задлъжняване, както и останалата част от тяхната работа.
Обсъждани ли са техническите дебитни задължения на базата на разширяване на базата на разширяване или те са просто непрекъснати и обикновено не са обвързани с конкретен цикъл на разширяване?
И двете.
Какви технически дефицити по дългове бяха разгледани за разширяването на Odyssey?
За да назовем някои от тях: Ние подобряваме корекциите (имаше малък брой неуспехи при използване на HTTP / 1.0 прокси), пренаписване на процеса на генериране на колекция от експортирани изображения и обновяване на обработката и регистрирането на EVE API, както и метода на внедряване. на API и актуализиране на нейния вътрешен механизъм за кеширане (локален и разпределен).