3 ポイント 投稿者 GN⁺ 2024-10-01 | 1件のコメント | WhatsAppで共有

技術的負債の分類

紹介

  • Bill "LtRandolph" Clarkは、LoL のChampionsチームのエンジニアリングマネージャーであり、技術的負債に深い関心を持っている。
  • 技術的負債は、将来の開発者にコストをもたらすコードやデータと定義される。
  • この記事では、Riotで経験したさまざまな技術的負債の種類と、社内で使用しているモデルを紹介する。

メトリクス

技術的負債を評価するために、3つの主要な軸を使用する: 影響、修正コスト、伝染性。

影響

  • 技術的負債がプレイヤーと開発者に及ぼす影響。
  • バグ、欠落した機能、予期しない動作など。

修正コスト

  • 技術的負債を修正するのに必要な時間とリスク。
  • 単純なエラーは数分で修正できるが、深く根付いた問題は数週間または数か月かかることがある。

伝染性

  • 技術的負債がどの程度広がりうるか。
  • 他のシステムとの相互作用、データのコピー、新機能の実装に影響する。

負債の種類

ローカル負債

  • システム内部でのみ問題が発生し、外部には影響しない。
  • 例: JarvanのCataclysm。
Cataclysm メトリクス
  • 影響: 1 / 5
  • 修正コスト: 2 / 5
  • 伝染性: 1 / 5

マクガイバー負債

  • 2つの相反するシステムが、その場しのぎで結合されている場合。
  • 例: C++の std::string とRiotのAStringクラス。
std::string vs AString メトリクス
  • 影響: 2 / 5
  • 修正コスト: 3 / 5
  • 伝染性: -2 / 5

基盤負債

  • システムの深い部分にある前提が、システム全体に影響を及ぼす場合。
  • 例: LoL のluaスクリプト言語の使用。
BlockBuilder Lua メトリクス
  • 影響: 4 / 5
  • 修正コスト: 4 / 5
  • 伝染性: 4 / 5

データ負債

  • 他の種類の技術的負債の上に大量のコンテンツが積み重なり、修正が難しく危険になっている場合。
  • 例: BlockBuilderスクリプト言語のパラメータ名バグ。
パラメータ名バグ メトリクス
  • 影響: 2 / 5
  • 修正コスト: 2 / 5
  • 伝染性: 4 / 5

要約

  • 技術的負債を評価する際には、影響、修正コスト、伝染性を考慮する必要がある。
  • 伝染性は技術的負債が広がる可能性を示し、これを無視すると大きな問題になりうる。
  • 技術的負債は、ローカル負債、マクガイバー負債、基盤負債、データ負債の4種類に分類できる。

GN⁺のまとめ

  • この記事は、技術的負債の種類とその評価方法を説明することで、開発者がより良い意思決定を行えるよう支援する。
  • 技術的負債の伝染性を強調し、問題を早期に解決することの重要性を強調している。
  • 類似した機能を持つ他のプロジェクトとして、Dota 2Overwatch がある。

1件のコメント

 
GN⁺ 2024-10-01
Hacker Newsの意見
  • インターフェースはデザインにおいて最も重要な要素の1つであり、慎重に検討すべき

    • 美しいインターフェースは時間さえあれば簡単に改善できるが、その逆はまれ
  • 創業者の負債は、創業者たちが速く優れた技術を提供するために生み出した負債である

    • 多くの国の建国文書もこのカテゴリに含まれる
  • この記事がエンジニアリングマネージャーによって書かれたことに驚く

    • 内部昇進したマネージャーはおらず、外部採用する傾向がある
  • 技術的負債の分類について議論されている

  • 技術的観点から見て素晴らしい記事

    • 「命名法」のほうがより適切な表現かもしれない
    • 各例が非常に示唆に富んでいる
  • 技術的負債を説明するのに "Contagion" を使っている

    • 素晴らしい説明である
  • 技術的負債は、将来の開発者がコストを支払わなければならないコードやデータと定義される

    • 負債を発生させる際には、目先の必要性と将来のコストをバランスよく考慮すべき
    • 負債に対して病的な嫌悪感を持っている
  • 「ローカル負債」を一般的な状況で技術的負債とは呼ばないだろう

    • どこかには常に混乱があり、それをカプセル化するのが一般的である
  • 複数のスタートアップで働いた経験がある

    • 創業者たちは、アイデアと実際に実装されたもの、そして動いている部分を混同することが多い
  • 短期的な利益のために技術的負債を意図的に引き受けることがある

    • この利益も別の軸として考慮すべき