Inhalt
Dies ist der zweite Teil eines dreiteiligen Interviews. Sie können Lesen Sie hier den ersten Teil.
***
Mein Verständnis von agiler Entwicklung ist ziemlich grundlegend. Ich habe noch nie nach dieser Methode gearbeitet, aber hier und da ein wenig darüber gelesen. Was genau ist ein technischer Schuldenbestand?
Ein Rückstand ist eine Aufgabenliste. Es handelt sich jedoch um eine Aufgabenliste mit Prioritäten, die möglicherweise alle zwei Wochen (an den Sprintgrenzen) neu priorisiert wird, und die Teams verpflichten sich nur für ein zweiwöchiges Zeitfenster (einen Sprint). Ein technischer Schuldenbestand ist ein Unterabschnitt des gesamten Rückstands und der Storys (Aufgaben), die mit dem allgemeinen Rückstand verschachtelt sind.
Nun, das sagt mir keine Tonne, aber ich habe kurz gegoogelt, ein bisschen mehr gelesen und festgestellt, dass "Technical Debt das ist, was es schwierig macht, mit Code zu arbeiten. Es ist ein unsichtbarer Killer von Software und muss es auch sein aggressiv verwaltet. " Aus diesem Grund glaube ich, dass ich einen Aspekt Ihrer Arbeit viel besser verstehe. Modernisierung und Anpassung einiger älterer Codes in der EVE Online-Codebasis, wie z. B. das, was Crimewatch im letzten Jahr widerfahren ist.
Ich weiß, dass eine Überarbeitung des alten Unternehmens- und POS-Codes nicht in naher Zukunft geplant ist, aber wie aufgeregt wären Sie, wenn jemand sagen würde: "Schreiben wir das um und machen wir es richtig!"
Sie erinnern sich vielleicht an die Diskussionen, die in letzter Zeit um POSs stattgefunden haben. CCP Seagull kümmert sich um die Kommunikation zu diesem Thema. Ich könnte das Thema technische Verschuldung diskutieren, aber nicht im Zusammenhang mit POS.
Meinetwegen. Lassen Sie uns dies aus einer anderen Richtung angehen. Crimewatch. Jedenfalls ein altes, sehr zerbrechliches Stück Code. Es war sehr schwierig, damit zu arbeiten, und die meisten Projekte mieden die Interaktion, da dies zu unvorhergesehenen Problemen führen konnte. Wie weit waren Sie in den Prozess involviert, der sich auf das neue Design konzentrierte, als CCP die Entscheidung traf, diesen Code umzuschreiben? Wie viel Kontrolle geben Sie Projekten wie Crimewatch, um sicherzustellen, dass sie Ihren Standards entsprechen und die technischen Schulden auf Dauer nicht erhöhen? Wie glücklich waren Sie, als das Grünlicht gegeben wurde, Crimewatch neu zu schreiben?
In Bezug auf das tatsächliche technische Design nicht viel und nicht in das Spieldesign beteiligt. Der technische Vorsprung für die Game-Play-Teams (CCP Atlas) und vor allem für den Senior-Server-Programmierer (CCP Masterplan) im Team, das das neue System implementiert hat, waren die Leute in den Schützengräben für die eigentliche Entwurfsarbeit. Meine Aufgabe war es, die Tatsache hervorzuheben, dass der alte Crimewatch-Code spröde war. Vorsichtige Programmierer und Teams, die sich in diesen Code wagten und ihre Arbeit direkt überwachten, machten auf die Idee aufmerksam, dass er umgestaltet werden sollte, indem sie die Kosten aufzeigten, die das aktuelle System / der aktuelle Code uns verursachten und legen Sie die Standards für Implementierung und Leistungstests fest (der QS-Direktor ist für das Testen von Funktionen und allgemeine Testverfahren verantwortlich).
Ich war sehr froh, als dieses Projekt endlich grünes Licht erhielt. Es ist immer gut, diese Dinge von der Liste streichen zu können und dann zum nächsten System überzugehen.
Ich finde den gesamten technischen Rückstand Ihres Jobs faszinierend, zumal es sich um viele alte EVE-Kernsysteme handelt, mit denen die Spieler nur schwer arbeiten können und / oder die mit besseren, moderneren Funktionen überarbeitet werden möchten . Die KPCh hat diese Bereiche des alten, spröden Codes sorgfältig angegangen.
Würde das Corporate-Rollensystem in das Technical Debt Backlog fallen?
Bis zu einem gewissen Grad ist dieses System jedoch meist eine Frage dessen, was es leisten soll, und leitet daraus möglicherweise ein überarbeitetes Spieledesign ab. Der Code für dieses System ist nicht besonders schlecht.
"Nicht in schlechtem Zustand", in welcher Hinsicht? Aus Sicht der Spieler ist es schwierig, mit dem Rollensystem zu arbeiten, und Dinge, die die Leute erwarten würden, müssen oft mit verschiedenen ungeraden Workarounds ausgeführt werden. (Kelduum hat in seinen Kämpfen dokumentiert, dass einige dieser Problemumgehungen dazu führen, dass sich die Unternehmensrollen auf grundlegende Weise verhalten.) Ich nehme an, dass der Code in Anbetracht dessen, was er tatsächlich war und für was er nicht entwickelt wurde, in einem "guten Zustand" sein könnte. Die meisten Spieler würden zustimmen, dass es einer Überholung bedarf. Ist es für eine solche Überholung in gutem Zustand, wurde ihm Entwicklungspriorität eingeräumt?
Ich verwende im Rahmen des Technical Debt Backlog aus rein technischer Sicht „nicht in schlechtem Zustand“. Was Sie beschreiben, sind Usability-Probleme im System, was ich als "eine Frage dessen, was es erreichen soll und daraus möglicherweise ein überarbeitetes Spieldesign ableiten" bezeichnet habe. Aus technischer Sicht ist der Code selbst dann nicht so schlecht, vergleichsweise lesbar im großen Schema der Dinge und nicht schlecht strukturiert.
Welche Systeme fallen in den Technical Debt Backlog?
Das POS-System, der In-Game-Browser, Leistungsverbesserungen beim Client-Start, Leistungsverbesserungen beim Versenden von Physiksimulationsereignissen an Clients, Leistungsverbesserungen und Refactoring des Attributsystems; um ein paar zu nennen. Es gibt andere Systeme, aber es handelt sich entweder um Low-Level- oder interne Tools oder um Pipelines. Einige dieser oben genannten Systeme fallen in mehrere andere Kategorien. B. das POS-System hat Usability- und Design-Aspekte, von denen wir einige in Odyssey mit Quality of Life Improvements ansprechen.
Wer trifft die endgültige Entscheidung darüber, welche Positionen des Technical Debt Backlog angegangen werden?
Letztendlich ist es der Senior Producer, der anruft, was der Rückstand für jede Veröffentlichung enthält. Sie bittet verschiedene Parteien um Beiträge zu den Prioritäten und versucht, die verschiedenen technischen und geschäftlichen Bedürfnisse in Einklang zu bringen. Die Positionen im Technical Debt Backlog sind unterschiedlich groß und daher kann eine kleinere Aufgabe früher erledigt werden (weil sie in den Zeitplan passt), selbst wenn sie eine geringere technische Priorität als eine größere Aufgabe hat. Wo es signifikante Änderungen in der Spielmechanik geben wird, wie zum Beispiel bei Crimewatch, fällt dies in den Zuständigkeitsbereich des führenden Spieldesigners.
Trotzdem müssen Sie noch einiges zu diesen Prioritäten beitragen. Ich würde mir vorstellen, dass der Senior Producer sich auf Ihr Fachwissen und Ihre Erfahrung mit dem Technical Debt Backlog verlassen muss.
Da ich weiß, wie der Senior Producer die unterschiedlichen Bedürfnisse ausgleichen muss, sende ich ihr keine einzige Prioritätenliste. Vielmehr diskutiere ich den Rückstand mit ihr und die relative Bedeutung und mögliche Größe jedes Projekts zusammen mit der Frage, wie das Durchführen bestimmter Aufgaben des technischen Schuldenrückstands andere Dinge für sie ermöglichen und wie das Nichtdurchführen bestimmter Aufgaben des technischen Schuldenrückstands uns möglicherweise in eine Ecke treiben kann ".
Werden Technical Debt Backlog-Posten von einem bestimmten Team bearbeitet? Oder werden sie an Teams verteilt, die am besten mit ihnen umgehen können (d. H. Teamkenntnisse)
Sie werden von allen Teams gehandhabt, obwohl Team Gridlock, wie es für den Rest ihres Rückstands und ihres Fachwissens angemessen ist, nur an Aufgaben des technischen Schuldenrückstands beteiligt war.
Werden die Posten des Technical Debt Backlog auf Expansionsbasis angegangen oder dauern sie nur an und sind im Allgemeinen nicht an einen bestimmten Expansionszyklus gebunden?
Beide.
Welche Positionen des Technical Debt Backlog wurden für die Odyssey-Erweiterung in Angriff genommen?
Um nur einige zu nennen: Wir verbessern das Patching (bei Verwendung von HTTP / 1.0-Proxys sind nur wenige Fehler aufgetreten), schreiben den Generierungsprozess der Image Export Collection neu und überarbeiten die Fehlerbehandlung und -protokollierung in der EVE-API sowie die Bereitstellungsmethode der API und Aktualisierung des internen Caching-Mechanismus (lokal und verteilt)