Зміст
Це другий з інтерв'ю з трьох частин. Ти можеш прочитайте тут першу частину.
***
Моє розуміння гнучкого розвитку є досить простим. Я ніколи не працював за методологією, але прочитав трохи про це тут і там. Що таке технічне відставання заборгованості?
Відставання - це список завдань; але це список пріоритетних завдань, який може бути переорієнтований кожні два тижні (на спринтерських кордонах), і команди лише зобов'язуються протягом двох тижнів (один спринт). Технічне відставання заборгованості є підрозділом загального відставання та історій (завдань), які переплітаються із загальним відставанням.
Ну, це не говорить мені тони, але я зробив швидкий google, трохи більше читав, і визначив, що "Технічний борг - це те, що робить код важко працювати. Це невидимий вбивця програмного забезпечення, і він повинен бути агресивно. Виходячи з цього, я вважаю, що я розумію один аспект вашої роботи набагато краще. Модернізація, доведення до стандартів, частина старого коду в базі коду EVE Online, наприклад, що сталося з Crimewatch минулого року.
Я знаю, що будь-яке оновлення старого корпоративного та POS-коду не належить до розробки в найближчому майбутньому, але наскільки ви збудилися б, якби хтось сказав: "Давайте перепишемо це і зробимо це правильно!"
Можна згадати дискусії, що відбувалися недалеко від POSS; КПК Чайка обробляє зв'язок з цього питання. Я міг би обговорити тему технічного боргу, але не в контексті позицій.
Справедливо. Давайте вирішувати це з іншого боку. Crimewatch. За всіма даними, старий, дуже крихкий шматок коду. З ним було дуже складно працювати, і більшість проектів уникали взаємодії з нею, оскільки це могло викликати непередбачені проблеми. Коли КПК прийняла рішення переписати цей код, як ви були задіяні в процесі, який зосереджувався на новому дизайні? Скільки нагляду ви надаєте таким проектам, як Crimewatch, щоб переконатися, що вони відповідають вашим стандартам і що вони не додають технічної заборгованості? Як ви були щасливі, коли було дано перезаписати Crimewatch?
З точки зору фактичного технічного проектування, не багато, і не задіяні в ігровому дизайні. Технічна перевага для команд гри (CCP Atlas) і в першу чергу старшого серверного програміста (CCP Masterplan) в команді, яка впровадила нову систему, були людьми в траншеях для фактичної проектної роботи. Моя роль полягала в тому, щоб підкреслити той факт, що старий код Crimewatch був крихким, обережним програмістам і командам, які заглиблювалися в цей код і безпосередньо контролювали їхню роботу, пропагували ідею, що вона повинна бути перероблена, демонструючи вартість поточної системи / коду і встановлює стандарти для впровадження та тестування продуктивності (директор QA відповідає за тестування функцій та загальну практику тестування).
Я був дуже щасливий, коли цей проект нарешті був освітлений; Це завжди добре, щоб перетнути ці речі зі списку, а потім перейти до наступної системи.
Я вважаю, що вся технічна заборгованість у вашій роботі захоплююча, тим більше, що вона обертається навколо великої кількості старих, основних систем EVE, з якими гравцям важко працювати і / або хотіли б бачити рефакторінг з кращими, більш сучасними функціями . КПК була обережна у вирішенні цих проблем старого, крихкого коду.
Чи буде система корпоративної ролі потрапити в технічний борг?
Певною мірою, але в основному ця система - це питання про те, що вона повинна виконати, і звідти можливо вивести нагальний дизайн гри. Код цієї системи не має особливо поганої форми.
"Не в поганій формі", в чому? З точки зору гравця важко працювати з рольовою системою, і речі, які люди очікують від них, часто повинні виконуватися з різними незвичайними обхідними шляхами. (Kelduum задокументував деякі з цих обхідних шляхів у своїй боротьбі, щоб корпоративні ролі поводилися певним чином.) Я припускаю, що код міг би бути в "хорошій формі", враховуючи те, що він насправді був і не був розроблений. Більшість гравців погодиться з тим, що їй необхідний капітальний ремонт. Чи є вона достатньою для такої реконструкції, чи була вона приділена пріоритету розвитку?
Я використовую «не в поганому стані» в контексті технічного боргового боргу з чисто технічного аспекту. Те, що ви описуєте, є питаннями юзабіліті в системі, що я називаю "питанням про те, що він повинен виконати, і звідси можливо отримати реконструйований ігровий дизайн". З технічної точки зору сам код не є таким поганим, порівняно читаним у великій схемі речей і не погано структурований.
Які з цих систем потрапляють в технічний борг?
POS-система, браузер в грі, поліпшення продуктивності для запуску клієнта, поліпшення продуктивності диспетчеризації подій фізичного моделювання клієнтам, поліпшення продуктивності та рефакторинг системи атрибутів; назвати декілька. Є й інші системи, але вони є або низьким рівнем, або внутрішніми інструментами або конвеєром. Деякі з перерахованих вище систем поділяються на декілька інших категорій; така система POS має зручність та аспекти дизайну, деякі з яких ми розглядаємо в «Одіссеї» з покращенням якості життя.
Хто приймає остаточне рішення про те, що буде розглянуто в Технічному стані?
Зрештою, головний продюсер робить виклик того, що містить відставання для кожного випуску. Вона прагне отримати інформацію від різних сторін щодо пріоритетів і намагається збалансувати різні технічні та бізнес-потреби. Елементи Технічного Блоку Технічного Боргу мають різні розміри і тому менше завдання може бути зроблено раніше (тому що воно вписується в графік), навіть якщо має менший технічний пріоритет, ніж більша задача. Там, де відбудуться значні зміни в ігровій механіці, наприклад, з Crimewatch, це підпорядковане компетенції ведучого дизайнера гри.
Незважаючи на це, ви повинні мати ще чітку інформацію щодо цих пріоритетів. Я можу уявити, що старший виробник повинен покладатися на ваш досвід і досвід з технічним боргом по технічному боргу?
Знаючи, як старшому виробнику потрібно збалансувати різні потреби, я не надсилаю їй жодного пріоритетного списку; скоріше, я обговорюю відставання з нею, а також відносну важливість і можливий розмір кожного проекту, а також те, як виконання певних завдань Технічного Блоку Технічного Боргу може дозволити іншим для неї, і як не можна виконувати інші завдання Технічного Заборгованості Заборгованості, можливо, "намалювати нас у кут ".
Чи підлягають технічні заборгованості заборгованості певні команди? Або вони роздаються командам, на основі яких вони можуть найкраще мати справу з ними (наприклад, досвід команди)
Вони обробляються всіма командами, хоча Team Gridlock брав участь у виконанні лише завдань з технічного заповнення технічного боргу.
Чи розглядаються питання технічного боргового резерву на основі розширення за розширенням, або вони просто тривають, і взагалі не прив'язані до конкретного циклу розширення?
Обидва.
Які предмети технічного боргового заповнення були вирішені для розширення Одіссеї?
Назвемо лише декілька: ми вдосконалюємо виправлення (було незначне число збоїв при використанні проксі HTTP / 1.0), переписуючи процес генерування колекції експорту зображень та обробку помилок та реєстрацію в EVE API, а також метод розгортання. API та оновлення механізму внутрішнього кешування (локальний та розподілений).