この記事は、GOTO Berlin 2017カンファレンスに出席した報告書の無料の改版です： 技術的な負債を優先するためのクリスタルボール 。
レポートの画像とそれらの権利は、著者@AdamTornhillに属します。
各開発者は、原則として、技術的負債とは何かを理解しています。 彼のプロジェクトでは、この負債はおそらく存在するでしょう。 運が良ければ、彼は長い間書き直されるように頼まれてきたいくつかのコードを思い出すでしょう。
しかし、技術的負債の概念を他の人に説明するためにどのように形式化するのでしょうか？ さらに、リファクタリングの承認を得るような方法で、マネージャーに説明してください。 プロジェクト内の適切な方法で書き換える必要があるすべての場所を見つける方法、および最初に書き換える必要がある場所を決定する方法は？
これらの質問が繰り返し発生する場合は、猫の下でお願いします。
不器用に記述されたコードのすべてが、定義上、技術的な義務ではありません。 もちろん、そのようなコードがある場合は、遅かれ早かれ書き直した方が良いでしょう。 しかし、コードをほぼ無限に洗練できることは誰もが知っています。 どのコードが技術的義務であるかを判断する方法は？
技術的な負債のかなり良い説明は 、マーティン・ファウラーによって与えられました：
金融負債のように、技術負債は利子の支払いを招きます。これは、迅速で汚れた設計の選択のために、将来の開発で行わなければならない余分な努力の形でもたらされます。つまり、コードの一部のために開発中に費やす労力が増えるほど、技術的負債が大きくなります。 これに異議を唱えることは困難ですが、それでもどの場所を書き換えるべきかを明確に決定するには十分ではありません。
各特定のファイル/クラス/関数が開発に費やす時間を評価するために、Adamはホットスポットの概念、ホットスポットを紹介します。 そして、これらのホットスポットを検索するには、ほとんどすべての開発者が持っている1つのツール、つまりバージョン管理システムだけが必要です。
このファイルの変更頻度とこのファイルの難易度を調べることで、コードでファイルをサポートするための労力を見積もることができます。 変更の頻度を評価することで、すべてが明確でシンプルになります。 複雑さは、好みに応じてさまざまな方法で評価できます。 最も単純なケースでは、これはファイルサイズまたはコードの行数です。 他の条件が同じであれば、100行のコードを持つファイルを維持することは、1000行のコードを持つファイルよりもはるかに簡単です。 ケースのファイルサイズが複雑さを評価するための基準ではない場合、複雑さの静的評価にさまざまなユーティリティを使用できます（たとえば、循環的）。
次に、ホットスポットを次のように識別できます。
Tomcatプロジェクトでホットスポットを見つける例を次に示します。
大きな青い円はフォルダーです。 小さなファイル。
このすべてにおいて、ホットスポットの存在は、このファイルに問題があることを意味するものではありません（ほとんどの場合問題です）。 これは、これらのファイルで最も時間を費やすことを意味します。 また、これらのファイルをリファクタリングするときは、リスト内のコードがクリーンで、メンテナンスが容易で、拡張可能であることを確認するために、リストの最初にする必要があります。
また、例として、可能な限り異なる複数のプロジェクトのコード分析のグラフが示されています。 異なる言語、異なる寿命、異なるソフトウェア会社。 X軸にはファイルがあり、Y軸には変更の頻度があります。
すべてのプロジェクトには同じパターンがあります。 ほとんどのコードはチャートの末尾にあります。 したがって、非常に頻繁に変更されるファイルのごく一部があります。 これらのファイルは、リファクタリングの最初の候補でもあります。
ホットスポットを検索する場合、さらに深くすることができます。 そして、すでに個々の機能のレベルで問題のあるファイル内のホットスポットを探します：
そのようなホットスポットの検索に使用されたツール-codescene.io
コードの複雑さを定期的に監視することもお勧めします。 このようなデータをグラフ形式で分析すると、迷った瞬間に非常に明確に表示されます。
まとめ
このレポートは、主に技術的負債とその規模の明確な定義のために、私にとって有用であると思われました。
ホットスポットを特定してコードをこのように真剣に分析するためには、技術的な負債で非常に行き詰まっている必要があることは明らかです。 しかし、基本的なレベルでさえ、日常業務では、私が最も頻繁に触れるクラスに注意を払い始め、そのようなクラスをゆっくりとリファクタリングしようとしています。
また、ボーナスとして（レポートに関する聴衆からの質問がありました）、Adamは経営陣にリファクタリングの必要性を適切に伝える方法を話しました。 ほとんどの場合、管理者は技術的な人ではなく、コードからかなり離れています。そうでなければ問題はありません。 しかし、これらの人々がよく理解しているのは数字とグラフです。 適切に情報を伝えるには、同じ言語で話す必要があります。 ここでは、ホットスポットと時間依存のコードの複雑さを示すグラフのみが役立ちます。 グラフでは、最近追加したこの種の機能により、新機能の追加が非常に複雑になっていることがわかります。 したがって、将来的に開発のペースを加速したい場合、リファクタリングに時間をかける必要があります。
便利なリンク：
- コード分析とアーキテクチャに関するAdamの新しい本
- ホットスポットの概念についても説明されている記事ですが、私には思われたように、並んで説明されています。 私は、問題のある領域の検索と技術的負債との関係を強調したかった。
- レポート自体のビデオ