こんにちは、私の名前はビル「LtRandolph」クラークです。 私はLoL Champion Teamのテクニカルマネージャーとして働いています。 過去数年間、私はリーグ開発のさまざまな部門で働いていましたが、私が常に取りつかれていたのは技術的負債だけでした。 私は彼を見つけ、理解し、可能であれば彼を排除する必要があります。



パッチ8.4 League of Legendsなど 、既存の技術について開発者が議論するとき、技術的な負債に言及することがよくあります。 将来の開発者が支払う必要がある技術的な負債コードまたはデータを呼び出します。 ソフトウェア開発のこの悲しい側面に、無数の投稿、記事、および定義が捧げられてきました。 私の投稿では、Riotで働いている間に会わなければならなかった技術的負債の種類について話し合い、会社で使用し始めたモデルについて話したいと思います。 この記事から学ぶことができる最も重要な教訓を強調するように求められた場合、これは以下で説明する「感染」の指標であると言えます。

指標

どの問題を今すぐ修正する必要があり、どの問題を後で設定するか（または、現実的に考えて、それらを完全に忘れる）について適切な決定を下すために、技術コードの特定の各要素を測定する方法が必要です。 評価には、影響、排除コスト、感染の3つの主要な測定軸を選択しました。

影響力

最初の軸は最も明白です：負債の影響。 プレーヤー（バグ、機能の欠落、予期しない動作）および開発者（実装の遅延、ワークフローの問題、覚えておく必要のある無意味なナンセンス）が直面する問題の形をとります。 「開発者」とは、ゲームのあらゆる作成者があらゆる側面で作業していることを意味することに注意してください。 新しいコードを書くプログラマーは技術的負債の一部に対処する必要があり、他の部分はデザイナーが新しいスクリプトを作成できないようにし、エフェクトアーティストが新しいパーティクルシステムを作成できないようにします。

消去費用

2番目の軸は、技術的負債を取り除くコストに関連しています。 コードまたはデータの問題を修正する場合、ある程度の時間を要します。 これがゲーム内のすべてのコード行に影響する根深い仮定である場合、数週間または数か月の開発時間がかかる可能性があります。 これが1つの機能の愚かな間違いである場合、数分で修正できます。 修正の実装にかかった時間に関係なく、そのような修正を導入するリスクも考慮する必要があります。 私が「悪い」と考えるシステムでさえ、素晴らしいゲームを作成するためのツールとして使用できます。 スクリプトエンジンによるエラーの処理方法を変更したり、パーティクルの作成時間を計算するときに変更すると、140を超えるゲームチャンピオンの500を超えるスペルの動作が台無しになります。

感染症

3番目の軸は、私が取りつかれているもの、つまり感染を測定します。 技術的義務の継続が許可される場合、それはどこまで広がりますか？ この広がりは、他のシステムが債務の影響を受けるシステムと相互作用すること、システム上で作成されたデータのコピー＆ペースト、または他の開発者が新しい機能を実装する方法に影響するために発生します。



技術的負債の断片が十分に制限されている場合、将来のその除去のコストは現在とほぼ同じです。 修正の必要性を考慮して、今日その影響を比較検討することができます。 一方、負債の一部が非常に伝染性である場合、それを除去することは徐々に難しくなります。 伝染性の技術的負債に特にうんざりするのは、その根底にある技術的妥協にますます多くのシステムが感染すると、その影響は成長する傾向があるということです。

負債の種類

技術的負債の各特定の要素を測定するシステムができたので、 League of Legendsで気づいた技術的負債のいくつかの一般的なカテゴリーを議論しましょう。

地方債

地方債は、プログラミングの古典的なブラックボックスモデルに似ています。 ゲームの残りの部分に関する限り、ローカルシステム（スペル、ネットワークレイヤー、スクリプトエンジン）はかなり信頼できるように見えます。 システムに触れることなく開発を行っている間、誰も借金を念頭に置くべきではありません。 しかし、誰かが蓋を開けて中を見ると、彼は自分が見ているものに驚くでしょう。









私たち自身の目には、現実世界からの地方債務の例がいくつかあります。 目の構造的な特徴により、すべてが逆さまに見えます。 さらに重要なことは、網膜神経が各目の中央に盲点を作ることです。 この歪んだデータは脳の視覚中心に送信され、脳の残りの部分が「正しい」画像と対話できるように、画像を裏返して死角を埋める必要があります。 これらの癖は、目/視神経系に局在化しており、他のシステムでは容易に回避されるため、「十分」です。









リーグ・オブ・レジェンドの地方債の最も有名な例の1つは、まだ手下で構成されているジャーヴァン大変動です。 デザイナーがゲームプレイエフェクトをポイント（または複数のポイント）に結び付ける必要がある場合、利用可能なツールの1つは「見えないミニオン」を作成する機能です。 私が「ミニオン」と呼ぶものは、RiotXypherousによってここに記述されています 。 これらのゲームオブジェクトは、スクリプトロジックを追跡および実行するための安定したよく理解された方法です。 Jarvanの壁のような場合、誰も壁を通り抜けることができないように、多数のミニオン（正確には24個）を作成する必要があります。 別の解決策は、大変動を通過する可能性を制御する単一の論理要素で構成されるリングリリーフ設計です。 このアプローチを使用すると、ロジックをクリーンアップし、計算コストをわずかに削減できます。 影響/コスト/感染モデルの大変動を見て、それを修正することが現在のところ最善の選択肢ではない理由を見てみましょう。

激変メトリクス

1.影響：1/5

以前は、12個のミニオンが作成されたときに、人々は時々壁を通り抜けることができたため、Riot Exgeniarはその数を24に増やしました。壁がミニオンでできているという事実は、新しいコンテンツを作成するプロセスの他の開発者にほとんど影響を与えません。 （小さな余談：悪名高い「 Ult Hitch Jarvana 」は、この義務と、自動攻撃の定義の欠落を読み取ろうとする試みに起因するブートバグの組み合わせによって引き起こされました。）

2.消去のコスト：2/5

これまでのところ、新しいコードを作成せずに図形を描画して任意のジオメトリを作成する方法はありません。 「エリアトリガー」の実装用のリングを作成して、Jarvanバリアがより効率的に機能するようにするには、リングとの衝突を計算するための特別な数学的計算を記述する必要があります。 他の目的に構造ソリッドジオメトリを使用します。これにより、修正コ​​ストを大幅に削減できます。

3.感染：1/5

新しい機会を開発するとき、誰もジャーバンの壁の実装を考慮に入れるべきではないので、それは十分に制限されています。 感染の唯一のリスクは、他の設計者がこの実装を新しいチャンピオンにコピーできることです（これは時々発生します）。 しかし、実装の問題がどこまで進んでも、大変動の潜在的な広がりは低く、十分に理解されています。



これはかなり典型的な地方債務です。 ほとんどの場合、地方債は低い感染率によって特徴付けられます。 影響が除去のコストより高い場合、通常、手遅れになる前に意識のある開発者によって負債が除去されます。



地方の借金をなくすかどうかを決めるとき、まず質問を自問してください。 借金が実際に伝染しない場合は、必要な時間だけ借金を放置するのに十分安全です。 私が遭遇する最大の過ちの1つは、開発者の完璧主義によって引き起こされる現地の負債を取り締まるという本能的な欲望です。実際、負債の影響は努力を正当化するものではありません。 修正を行うことにした場合、変更の局所性により、修正および回帰テストは通常​​簡単です。



地元の借金をなくす最近の例には、モデレーターのバグ、チャンピオンを強制的に座標0,0,0、モンスーンジャンヌに追いやる、スペルシールドを無視する、女神の涙の呼び出しスタックがマナのコストなしで含まれます。

マクガイバーデューティ

マクガイバーの借金は、80年代半ばのテレビシリーズにちなんで名付けられました。 アンガス・マクガイバーは、スイスのアーミーナイフ、電気テープ、手元にあるアイテムの助けを借りて問題を解決しました。









彼の決定はしばしば2つの予期しない部分の組み合わせを使用しました。 技術的負債の文脈では、これは、2つの競合するシステムが、コードベース内の相互作用の場所で「電気テープ」によって互いに固定されていることを意味します。









シアトル（他の多くの都市と同様）には、上記のマクガイバーの借金の悲しい例があります。 市内には2つの競合する集落があり、それぞれに独自のブロックのグリッドがありました。 これらの集落が近代的なエメラルド都市に成長したとき、わずかに異なるネットが組み合わされ、ひどい形の近隣や建物、そして完全に非効率的なスペースの使用をもたらしました。 左下隅にある建物のこの小さなカットオフコーナーに特に驚かされます。



LoLコードベースにおけるMcGyverの負債の最も良い例の1つは、独自のAStringクラスとともにC ++のstd :: stringを使用することです。 これらは両方とも、文字列を保存、変更、および渡す方法です。 一般的なケースでは、std :: stringは多くの「隠された」メモリ割り当てと計算コストにつながり、それらで悪いことをするコードを簡単に書くことができることがわかりました。 AStringは、サウンドメモリ管理を念頭に置いて特別に設計されています。 std :: stringをAStringに置き換える戦略は、両方をコードベースに存在させ、2つのタイプ間の変換を提供することでした（それぞれ.c_str（）と.Get（）を使用）。 AStringには実装が容易で作業しやすいように多くの改良を加え、コードを変更するプロセスでstd ::文字列をゆっくりと置き換えることを開発者に奨励しました。 したがって、std :: stringを徐々に置き換え、2つのシステム間のスコッチインターフェイスを徐々に狭めていきました。

Metrics std :: string vs AString

1.影響：2/5

現時点では、影響力の大きいstd ::文字列メモリ割り当てのほとんどはプロファイリングに取って代わられているため、現在の主なコストは、あるシステムから別のシステムに切り替えるための少しの精神的な努力です。

2.消去のコスト：3/5

AStringへの変換は、単なる検索および置換タスクではありませんでした。 AStringには、さまざまな目的でいくつかの側面があります（動的メモリ割り当てを備えた基本的なAStringに加えて、メモリ内のスタックの初期位置用のAStackStringと、静的文字列へのリンク用のARefStringがあります）。 適切な実装のために、本物の、考えている人は、交換ポイントを見るべきです。 古いシステムの混雑は、長くて遅いプロセスになります。

3.感染：-2 / 5

AStringをstd :: stringより簡単に動作させることで、実際に感染を包み込みました。 開発者がゲームコードを変更するたびに、AStringがウイルスのようにさらに広がる可能性があります。



通常、McGyverの借金の最大のコストは知的財産であり、国境を越えるときに思考のモードを切り替えるのに必要です。 ある種のバグや機能が「間違った」システムにあるために保存されている場合、論理的なステップは通常「正しい」システムへの移行です。 ここで、監視する重要なメトリックは、新旧システムの伝染率です。 新しいシステムを優先してバランスを逆転できる場合、最高のシステムが必然的に勝ちます。



マクガイバーの借金をなくす必要性を検討する際には、地域レベルで望ましい（グローバル）システムを改善する方法を見つけるよう努めてください。 毎日の仕事で貪欲な最適化を実装する期間限定の開発者が、目的の最終状態に移行することを決定した場合、あなたは正しい軌道に乗っています。



動作する可能性のある別のアプローチは、大規模なブルートフォースリファクタリングです。 システムの密接な接続により、Withな正規表現の助けを借りて、McGyverの負債の一部またはすべてを排除することができます。

基本債務

基本的な義務とは、特定の仮定がシステムの中心に非常に深く存在し、そのすべての作業と密接に関連している場合です。 システムの経験豊富なユーザーは、基本的な義務を認識するのが難しい場合があります。









現実の世界における根本的な負債のばかげてばかげた例は、アメリカの測定システムとして知られる測定システムです。 私はアメリカで育ち、私の脳は役に立たない変化に満ちています。たとえば、1マイルが5280フィート、1クォートが2パイント、1ガロンが4クォートであることを覚えています。 米国政府は、メトリックシステムへの切り替えを何度も決定していますが、国際単位系を公式の測定システムとして受け入れていない7か国のうちの1つです。 この義務は、道路標識、レシピ、小学校、人々の脳にあります。



技術ブログの以前の記事、たとえばLeague of LegendsやGame Data Serverでの決定論などで、Riotが苦労している基本的な負債の最大の断片について話しました。









基本的な負債のもう1つの例は、Luaスクリプト言語の使用です。 リーグデザイナーは、BlockBuilderと呼ばれるツールを使用して、機能ブロックを接続して複雑な動作を作成します。たとえば、ポイント間の距離の取得、ミニオンの作成、ダメージの付与、スクリプト実行の管理に取り組んでいます。 設計者が選択できる操作のセットは非常に大きいですが、制限されており、各操作のパラメーターは最小限です。 しかし、何年も前、 League of Legendsの先史時代に、データと一致する単純で制限された形式でブロックとパラメーターを保存しないことが決定されました。 代わりに、この目的のために、強力で美しく、非常に複雑なLua言語の配列とテーブルとして格納されるようになりました。 この決定がなされてから10年が経過し、今日ではエンジンで最も頻繁に行われる操作の1つがLuaオブジェクトの操作です。

BlockBuilder Luaメトリック

1.影響：4/5

luaとこのタスクスペースの不一致には多くのコストがかかります。 各呼び出しスタックは、BlockBuilderロジックのフレームごとに平均6つの順序付けられたスタックフレームで汚染されています。 これらの順序付けられた操作は、サーバーのCPU使用率の点では安くありません。 スクリプトの変更の違いを読むことは、不当に難しい作業です。 スクリプトファイルを解析/検索して機能を判断するには、Lua言語のかなり深い理解が必要です。

2.消去のコスト：4/5

Luaはエンジンに非常に深く組み込まれているため、それを掘り起こすことは困難な作業です。 現在、Luaオブジェクトのように動作するラッパークラスを作成する提案がありますが、スクリプトの内部をより適切なものに徐々に変換できるように、はるかに単純な内部構造を使用します。 しかし、このタスクにどのようにアプローチしても、慎重かつ思慮深くする必要があります。

3.感染：4/5

システムがスクリプト（ LoLロジックの基本単位）に遭遇するたびに、このシステムはLuaバックエンドの操作と要件によって駆動されます。 平均して、3〜4日ごとに新しいビルディングブロックを作成します。 それぞれが直接Luaオブジェクトを操作します。 Luaを長期間交換しないほど、交換が難しくなります。



通常、基本的な負債は3つの軸すべてで高くなります。 コストが高いため、時代遅れのシステムに固執する必要がありますが、これは多くの場合正しい判断です。



暴動で最も頻繁に、基本的な負債を排除するための戦略は、古いシステムの隣に新しいシステムを構築することです。 可能であれば、基本的な負債をMcGyver負債に変換し、システムを徐々に移植して新しいシステムを使用することをお勧めします。新しいシステムと古いシステムの間で変換操作が行われる可能性があります。 これにより、リスクにさらされる可能性を減らしながら、ターゲット領域の活用を簡単に開始できます。 ただし、そのような変換は不可能な場合があります。 この場合、コンパイル中に（または、可能であればブート時に）トランジションを作成すると、カードにすべてを置くことなく、新しいシステムに自信を得ることができます。 コンパイルスキームはGDS変換で使用され、ロードスキームは確定性のために機能します。

データ負債

データの負債は、他のカテゴリの1つからの技術的な負債で始まります。 これは、スクリプトシステムのバグ、オブジェクトにとってあまり望ましくないファイル形式、または相互に適切に相互作用しない2つのシステムである可能性があります。 しかし、その後、コードのこの欠陥に加えて、 多数のコンテンツ（グラフィック、スクリプト、サウンドなど）が作成されます。 すぐに、元の技術的負債を修正することは非常に危険になり、それを修正しようとするときに何が壊れるかを言うのは非常に難しいことがわかりました。









データの負債を理解するための私のお気に入りの実世界の例はDNAです。 ゲノムは、損失（突然変異）、転写エラー、進化のプレッシャーを伴うコピーによって数百万年かけてゆっくりと成長した生物です。 コピーエラーには役に立たないものもありますが、無害なものもあれば、有害なものもありますが、大きな利点があるものもあります。 各DNAフラグメントが実際に何をしているのかを見つけることは非常に困難です。 塩基対の意味と、タンパク質を作成するために塩基対のセットがアミノ酸に変換される方法を完全に理解しています。 私たちは、コーディングに加えてDNAが果たすことができる役割のいくつかを理解し始めています。 しかし、ヒトゲノムの30億塩基対には、私たちがリモートでさえ理解していないものがまだ多すぎます。 Radiolab CRISPR エピソードでは、これらのパズルの1つがどのように解決されたかについて説明しています。



League of Legendsのデータの負債は、些細な修正を徹底的なテストに変えるときに最大の影響を及ぼします。 ほんの一例について説明しますが、信じられます。データの借金は、 LoLエンジンを変更する最も重要な理由の1つです。 当社のゲーム開発者は、ゲームシステムの実装に関する詳細な知識を持ち、一部のコードフラグメントが変更されたときにどのデータが破損するかを予測する十分なスキルを備えています。









数年前に修正されたデータ借金の忘れられない例は、スクリプト言語BlockBuilderのブロックパラメーターに関連付けられていました。 上の画像は、変数と定数によって所有者の鎧の値を増やす方法の例を示しています。 Ownerは25ユニットのアーマーボーナスを受け取ることを期待しています：Delta変数から20、ブロックに渡され、5は定数から。 ただし、変数名がパラメーター名と一致するため、このアクションでは40ユニットが追加されました。 （なぜ45ではないのかと聞かないでください。どのような思考プロセスがこれにつながったのかわかりません。）



NoopMoney Championsチームの開発者がこのとんでもない動作を修正し始めたとき、彼がしなければならなかったのは、4行のコードを削除することだけでした。 しかし、このような伝染性の高い債務の場合、小さな変更でも慎重な計画が必要です。 このバグにより、 400,000行のLoLスクリプトの数値パラメーターが2倍になる可能性があります。 さらに悪いことに、これらのスクリプトは、ゲームがこれらの2倍の値に対してバランスが取れて調整されているという意味で、「正常に動作しました」。 NoopMoneyは、（予期しないバグの場合）修正をリアルタイムで無効にし、正規表現の詳細な検索を実行し、品質管理部門を読み込んで、このバグのおかげでどのスクリプトが正しく機能するかを判断する必要がありました。 最終的に、このバグの修正による問題はかなり取るに足らないものでした。 少数のチャンピオングループのスクリプトに変更が加えられました。 しかし、データの負債により、予測が困難であることが判明しました。

パラメータの命名に関するバグメトリック

1.影響：2/5

このバグの出現は、ゲームにほとんど影響しませんでした。 彼は送信された値を2倍にし、定数を落とす確率がありました。 しかし彼は、デザイナーと開発者が（それらについて学んだ後）考慮に入れなければならない、もう1つの役に立たない集合的な知識になりました。 開発者の注意は、このように散らばるにはあまりにも貴重なリソースです。

2.消去のコスト：2/5

私が言ったように、修正プロセスは簡単でした。 リアルタイムの修正ロールバック機能を作成することにより、セキュリティの信頼性を高めることができました。 最も高価な部分は、ターゲットテストの問題の範囲を評価する初期分析でした。

3.感染：4/5

このバグで失敗したのは、非常に論理的な動作に基づいていたということです。 たとえば、ユニットにダメージを与えたい場合、ダメージ変数に値を保存することは完全に論理的です。 残念ながら、この値を受け取ったApplyDamageブロックには同じ名前のパラメーターがあり、バグにつながりました。 その後、他の誰かが同様の呪文を作成したいとき、彼は単にこれらのブロックをコピーして、バグをさらに広めました。



通常、データの負債を修正するコストは、変化を測定するのが難しいため高くなります。 より危険なことは、（コードとは対照的に）いくつかのデータプロパティのために、ほとんど常に非常に伝染性があることです。 最初に、既存のデータ要素をコピーして新しいデータ要素を作成することは一般に許容されると考えられています。 新しいスキルショットスペルを行う場合、エズリアルの神秘的なショットを基礎として使用することで、多くの時間を節約できます。 既存のデータ項目に関するすべての問題は、その子孫にまで及びます。 第二に、コードとは異なり、データが技術的な分析を受けることはほとんどありません。 したがって、たとえよく知られていたとしても、誤った慣行の広がりに気づき、止めることは困難です。 最後に、データのエラーを修正するには、目と脳のある人が通常必要です-コンパイラーと正式なロジックはそれらに対処しません。



データの借金をなくすために、2つの主なアプローチを見ました。 最初に「正しく実行」フラグを呼び出します。 データ作成者にとって、これは古い「壊れた」動作から新しい「修正された」動作に移行することを意味します。 理想的には、古いコンテンツが壊れたバージョンを使用していることが判明した後、改訂バージョンがデフォルトバージョンになるはずです。 その後、McGyverの借金の場合のように、ゆっくりと段階的な交換を開始して、新しいバージョンに切り替えることができます。 同時に、エディターのUIにナンセンスを追加するコストは常に一定です。



私が呼ぶ2番目のアプローチは、「間違いを修正する」だけです。 NoopMoneyは、パラメーター名のバグを修正するときに使用しました。 エラーを修正し、影響を受けたすべてのデータを修復することを意味します。 このタスクにはそれほど威圧的ではなかったので、いくつかのテクニックを使用できます。まず、バグの理論的な影響を評価するために、多くのgrepおよび正規表現検索を実行する必要があります。次に、ターゲットテストを実施します。最後に、修正中のバグよりも悪い何かを見逃した場合に備えて、修正の導入後に古い動作に戻るように切り替え関数を準備できます。また、決定論がこれらの種類の変更をテストする上で非常に役立ったことも注目に値します。変更の前後でサーバーが同じ結果を提供することを確認できました。

まとめると

技術的負債の例を評価する場合、影響（ユーザーおよび開発者に対する）、除去のコスト（一時的およびリスクの程度）、および感染のメトリックを使用できます。ほとんどの開発者が排除の影響とコストを定期的に評価していると思いますが、感染に関する議論はほとんど見ませんでした。問題の修正がますます難しくなると、感染が開発者の最も深刻な敵になる可能性があります。ただし、場合によっては、感染を自分の武器に変えて、問題よりも修正を伝染させることができます。リーグに



取り組むとき私が観察する技術的負債のほとんどは、これらの4つのカテゴリのいずれかに該当します。地方の借金は嫌な内容のブラックボックスのようなものです。2つ以上のシステムが変換機能と一緒にテープで固定されているのは、マクガイバーの負債です。基本的な義務により、構造全体はいくつかの失敗した仮定に基づいて構築されます。データの借金では、膨大な量のデータが他の種類の借金の上に階層化されるため、その修正はリスクが高く、時間がかかります。



この投稿が、技術的な負債について考え、議論するのに役立つ食べ物を提供することを願っています。