技術的負債を評価、管理、回避する方法
公開: 2020-05-26技術的負債が金融ハンドブックから取り上げられたように聞こえる場合、それはその用語が金融に関連しているためです。 しかし、本当の意味で、技術的負債はプログラミングに関連しています。 ソフトウェアプロジェクトの開発中に、特定の必要な手順がスキップされるか、期限に間に合わせるために完全に放棄されるという考えです。
完璧なアプリやソフトウェアを開発するために、開発者は、とにかく任意のタスクを実行するランダムな人と同じように、時間に縛られることがよくあります。 したがって、通常、完璧なコードで完璧な製品を提供することと時間を最大化することの間には、ある種のトレードオフがあることが理にかなっています。
問題は、これらのトレードオフに制限があるのかということです。 このトレードオフから生じる可能性のある固有の害はありますか？ 最後に、開発者は長期的には本当に良いのでしょうか？ 技術的負債に関するこの記事では、これらすべての質問に答えようとします。
技術的負債とは何ですか？
技術的負債を定義する際には、そもそもこの用語を生み出したとされている人物、ウォード・カニンガムを参照する必要があります。 カニンガムによれば、技術的負債とは、短期間でコードをプログラミングすることから生じる不足を補うために、コードのプログラミングに費やさなければならない余分な開発作業を指します。
よりグラフィックにするために、散らかった部屋の掃除を任されていて、クラスに遅れていると想像してみてください。 あなたが指示を実行し、またあなたのクラスに間に合うようにするために、あなたはソファの下の残骸のほとんどを一掃し、迅速な掃除をします。 これのフォールアウトは、あなたが最終的に混乱を分類するのに時間をかけなければならないということです。 ソフトウェア開発の場合、必要な手順をスキップして、「それほどクリーンではない」コードを使用してより簡単なルートをたどると、後でコードをクリーンアップするのが難しくなります。 ソフトウェアプロジェクトのドミノには複数のフェーズがあり、既存の問題を無視する時間が長いほど、解決にかかる時間が長くなります。
技術的負債の種類
技術的負債には、次のようなさまざまな種類があります。
計画された技術的負債
これは、組織が意図的に技術的負債を負うことを決定した状況で発生します。 これは、前述のように、通常、定められた期限を超えて特定の目標に到達するためのものです。 計画された技術的負債に従事するとき、組織は彼らが何を諦めようとしているのか、そして何を諦められないのかを明確にする必要があります。 最初にスキップしたエラーを最終的に返して修正する必要があることを念頭に置いて、正確な記録を保持する必要があります。
意図しない技術的負債
このタイプの技術的負債は、最初の負債とは正反対です。 これは、組織が技術的負債を予測または計画していない場合に発生します。 この理由は、通常、組織内のさまざまなユニット間のコミュニケーションの崩壊、またはユニット間のお粗末な作業慣行です。
避けられない技術的負債
これは、組織側のいかなる行動も防ぐことができなかった種類の技術的負債です。 たとえば、テクノロジーの急速な変化により、過去に作成された一部のコードが、現在予測されている標準を下回ることは理にかなっています。
また、この種の技術的負債は、コードがすでに記述されているときに変更が要求された場合に発生する可能性があります。 ソフトウェアの設計の途中で特定の変更が導入されると、ダイナミクスが台無しになり、古いコードが廃止されたり不要になったりする可能性があります。
技術的負債の原因
技術的負債の理由のいくつかは上で議論されました、しかし私はそれらをより明確にするために次々にそれらを選びます。
急いで
技術的負債の最も頻繁な原因は急いでいます。 多くの場合、開発者には厳しい期限があり、その中には特定のソフトウェアの起動期限が含まれているものもあります。 このような状況では、開発者が途中で技術的負債を負う可能性があることは、多くの場合理解できます（そして予想されます）。 この種の技術的負債は意図的なものであることが多く、コードにバグがあったり、スパゲッティコードが発生したりするなどの問題が発生する可能性があります。
見落とし/間違い
時々、プログラマーは悪いコードを書くだけで、最終的には技術的負債につながります。 コーダーのミスの結果として不良コードが存在するかどうかに関係なく、ミスは技術的負債をもたらし、スケーラブルではないため、最終的には修正する必要があります。
影響に対する認識の欠如
コーダーが長期的にどれほど有害な技術的負債であるかを認識または認識できないために、技術的負債が発生することがあります。 これは、プログラミング中にショートカットを使用することの有害な影響を正当に知らないことに起因する可能性があります。または、結果を故意に無視する可能性があります。
目的
技術的負債は、コーダーまたは組織の意図的な行動によって意図的に発生する可能性があります。
モジュール性の欠如
これは主に、1つのコードが同時に異なるビジネスロジックに対応できるために発生します。 このような状況では、ソフトウェアの処理が非常に難しくなります。 開発者がコードを作成するたびに、モジュール性の問題が発生する可能性が高くなります。
技術的負債の評価
技術的負債は非常に困難なため、手動で計算しないでください。 これは、現在の問題と将来起こりうる問題を特定するために、手動でコードを入力する必要があることを意味します。 手動プロセスの時間の浪費は別として、手動プロセスの最後にコードの形式が変更される可能性があります。
評価を実行する1つの方法は、それをサポートするいくつかのツールを使用して静的分析を実行することです。 使用できるツールには、Coverity、SonarQube、Check Style、ClosureCompilerなどがあります。
一般的に、技術的負債を計算する方法は2つあります。 最初のアプローチでは、コード比率に従って技術的負債の比率を計算することで取得できます。 ここでは、アプリの開発に必要な初期見積もりまたは全体の時間を使用して、技術的負債を修正するために必要な時間を決定します。
2番目のアプローチでは、SonarQubeなどのさまざまなツールによって提供される見積もりを直接利用できます。 これは、技術的負債のリストおよびそれらの参照コードと組み合わされます。 ツールから、それを修正するために必要な時間の長さの正確な見積もりを得ることができます。
技術的負債を評価することで、技術的負債を修正するのに何日かかるかがわかります。 借金が多ければ多いほど、それを修正するのに時間がかかります。
技術的負債の解決
技術的負債が発生し、何をすべきか途方に暮れている場合はどうなりますか？ 技術的負債を管理するために実行できる特定の手順があります。
まず、技術的負債が存在することを認識し、それをチームに伝える必要があります。 コミュニケーションでは、何が起こったのか、それを修正するために何をする必要があるのかを明確にする必要があります。 できるだけ早い機会に技術的負債を処理する必要性を明確に伝える必要があります。
チームに技術的負債を通知した後、3つのアプローチをとることができます。 最初のアプローチでは、システムをそのまま継続することを決定できます。 このシナリオでは、アプリケーションはそのまま使用されます。
または、アプリケーションをリファクタリングすることもできます。 リファクタリングは、アプリの複雑さを軽減し、アプリの構造をクリーンアップすることを目的として行われます。 リファクタリングを使用すると、ソフトウェアの動作は変更されません。 影響を受けるのは内部構造だけです。
最後に、上記の2つのオプションが機能しない場合は、コードを完全に置き換える必要があります。 これに関する1つの問題は、新しい技術的負債につながる可能性があることですが、長期的にはより良いトレードオフになる可能性があります。
将来の技術的負債の回避
もちろん、技術的負債を回避することは、技術的負債が発生したときにそれを修正しようとするよりも間違いなく賢明であることは簡単です。 それはあなたに時間とストレスの両方を節約するという事実とは別に、それはまた最初から技術的負債を持っていることから来る残りの結果がないことを確実にします。
技術的負債自体は悪くないと主張することができます。 それらは返済されなければならない借金であり、人間は地球上で最も責任のある種ではないため、一般的に問題があります。 一貫して弱いオプションを選択すると、通常、ソフトウェアの強度が弱まり、後で機能を改善することが難しくなります。 全体として、技術的負債を回避することは誰にとっても最善の策です。
では、どのようにして技術的負債の発生を防ぐのでしょうか。
ここでの考え方は、すべての人がプロセスに遅れないようにし、実行されているタスクの要件に合わせてスピードを上げることです。 バックログを作成すると、誰もが取り残されたタスクと、それらを達成するためのパスを確認できます。
あなた自身がプログラマーであるなら、あなたはたくさんの仕事よりも質の高い仕事を出すことを優先することを学ぶ必要があります。 コードがクリーンであり、アプリやその他のソフトウェアが完璧に開発されていることを確認してください。 最終的には、投棄したタスクを実行する必要があるため、ショートカットを使用する誘惑には価値がないことを理解してください。
チームを率いる場合は、これらの同じ価値観をチームメンバーに伝える必要があります。 メンバーは、結果指向のソリューションを作成し、ショートカットを回避するように教えられる必要があります。
一般に、技術的負債とは何か、そしてそれを回避する方法についての深い知識は、そもそも技術的負債の発生を防ぐのに役立ちます。 開発者に必要な知識を身に付けると、技術的負債がもたらす罠を回避することができます。
一部のコーディング手法では、技術的負債に陥る可能性が高くなります。 したがって、密結合を避け、抽象化とリファクタリングを採用するのは素晴らしいことです。
テクノロジーの定期的な更新は、技術的負債を未然に防ぐための優れた手段になります。 更新時には、使用されているものが最新のフレームワーク、データベース、およびアプリケーションソフトウェアであることを確認する必要があります。
結論
プログラムの開発とコードの記述を続ける限り、ほとんどの場合、技術的負債は避けられません。 ただし、上記の手順に従うと、発生する可能性を大幅に減らすことができます。 また、技術的負債が発生した場合でも、すべての希望が失われることはありません。 落ち着いて、自信を持って、それに応じて行動してください。