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