技術的負債とは何ですか？それを回避できますか？

公開: 2019-05-06

ソフトウェア開発をしている場合は、ある時点で技術的負債に対処する必要があります。それで、タイトルの質問に答えるために…いいえ、あなたはそれを避けることはできません。ただし、その影響を最小限に抑え、手に負えないようにするために実行できる手順があります。少なくともひどい。

技術的負債とは何ですか？

技術的負債は、それが時々呼ばれるように、本質的に、不完全なコードを持つために時間の経過とともに発生するコストです。ソースコードの変更と更新にはコストがかかります。開発チームへの新しいメンバーの追加、新機能の追加、バグの修正とエクスプロイトのパッチ適用も同様です。

プロジェクトが大きくなり、コードベースが拡大し、より多くの人々がそのコードに取り組むにつれて、彼らの声やスタイルはあちこちで衝突します。期限があり、理想的とは言えないソリューションがソースコードにパッチされて、時間どおりに終了する場合があります。おそらく、自分でコーディングするのではなく、機能を処理するために完全に理解していないオープンソースコンポーネントを追加します。または、ライブラリをバージョン間で切り替えることもできますが（たとえば、BackboneからReactに）、プロジェクトにレガシーコードベースを使用している人々をサポートする必要があります。

絶対にこれらのことのどれも悪いことではありません。単独ではありません。多分全然。しかし、合計すると、彼らが被る技術的負債は、将来のある時点で返済されなければならないでしょう。

ある時点で、そのオープンソースコンポーネントを交換（またはフォーク）する必要がある場合があります。それには時間とお金がかかります。遠い将来、プロジェクトからすべてのバックボーンコードを削除し、レガシーユーザーのサポートを停止する必要があります。繰り返しますが、時間とお金。締め切りに間に合わせるために行ったパッチは？まあ、それは最終的に元に戻され、より恒久的な修正が必要になります。時間とお金。また、チームの新しいメンバーが古いコードに戻ってこれらすべてを実行し、以前の開発者のコードとロジックを理解する必要があります。時間。お金。

あなたはそれを手に入れます。

技術的負債は抽象的な用語であり、しばしば比喩的ですが、技術的負債のコストは非常に現実的です。返済には金銭的価値があり、勤務時間と給与明細で支払う利息を追跡できます。あなたはそれをすべてのソフトウェア開発の一番下の行で見ることができます。

技術的負債を回避できますか？

前に言ったように…そうではありません。リリース後にコードに戻ると、作成するすべてのプロジェクトで技術的負債が発生します。ただし、技術的負債の種類を分類すると、プロジェクトでそれを最小限に抑え、さらには説明することができます。事前に借金を考えれば、自動車ローンや住宅ローンを借りるのと何ら変わりはありません。あなたは費用、利子、そして利益を見て、それからあなたがそれを支払うことができる/したいかどうかを決定します。

上で説明したいくつかの例を見て、コストを回避、最小化、または吸収する方法があるかどうかを確認しましょう。

意図的な技術的負債の検討

私たちが意図的な技術的負債と言うとき、私たちが意味するのは、あなたのチームが、あなたが取り組んでいるプロジェクトの言語またはタイプのいずれかのいわゆるベストプラクティスの範囲内にないことがわかっている決定を下したということです。締め切りがあるかもしれないと先に述べました。そして多分その締め切りは厳しくて速いです。たぶん、それが変更またはシフトされる可能性は0％です。

これは、ローンを組んで技術的負債を組むことを検討する必要がある場合です。

ここには実際に3つのオプションがあります。

未完成でバグのあるソフトウェアを出しますが、コードの明快さとロジックに譲歩はしません
完璧に管理できない機能をプルしますが、可能な限り適切に記述された機能をリリースします
すべてを実行するのに「十分に良い」コードを出す開発決定を下しますが、後で再度対処する必要がある可能性があります

ここでの3番目のオプションは、多くの場合、人々が選択するものです。それは技術的負債になります。そして、これには何の問題もありません。 あなたがそれをすることに決めたからです。

意図的な債務のローンの返済

このルートを選択する背後にある決定をコードに文書化してください。あなたがしたことと理想的な解決策が何であるかをメモしておいてください。また、この債務負担ソリューションが実装された場所（および、ご存知の場合は、プロジェクトの他の領域の影響を受けるシステム）を示すために、ソースコードに少なくとも何らかの解説を含めるようにしてください。この手順を実行しないと、プロジェクトへの追加（バグ修正やパッチであっても、新機能や拡張されたコードベースは言うまでもなく）は、完全なソリューションを期待するときにパッチワークソリューションを見つけることによって、ひどく遅れる可能性があります。

繰り返しになりますが、そのパッチワークソリューションは完全に問題なく、実際の問題を引き起こすことはありません。しかし、技術的負債はまだ存在しており、説明する必要があります。

レガシーコードの技術的負債を検討する

もう1つの一般的な種類の技術的負債は、WordPressが現在多く蓄積しているものです。 WordPressはPHP5.xで実行できます。ただし、最新のアップデートでは、少なくともPHP5.6である必要があることがユーザーに通知されます。 2019年末までに、WPコアにはPHP7.xが必要になります。ただし、要件を引き上げることにより、多くの古いコードを更新する必要があります。プラグイン、テーマ、およびCore自体にはまだPHP5.xコードが含まれているためです。

新しいブロックエディタは言うまでもありません。 JavaScriptで書かれています。具体的には反応します。それはPHPに近いものではありません。実際、WordPressCoreの多くはJavaScriptに少しずつ書き直されています。しかし、そのすべてのJSは、PHPも補完し、うまくやっていく必要があります。新しいテクノロジーを採用することは素晴らしいことであり、新しいバージョン管理要件を採用する必要があります。しかしそうすることで、あなたはそのソフトウェアがしばらくの間存在していたことからあなたが被る避けられない技術的負債に関心を払っています。

レガシーコードの債務の返済

それを行うための素晴らしい方法がないので、これは一種のタフです。核となるオプションを選択して、新しい言語/フレームワーク/バージョンでゼロから完全に書き直すことができます（Backbone.jsからReactに移行するDivi2とDivi3.0の間で行ったことを確認してください）。ただし、古いライブラリを使用している人がまだいるため、これでも債務の問題が完全に解決されるわけではありません。ある時点で、レガシーコードベースのサポートを終了する必要があります。これは、ローンを返済するようなものです。あなたが次のものを取り出さなければならないまで。

それがオプション（またはあなたにとって最良のアイデア）でない場合は、言語またはバージョン固有の機能に依存しないようにすることができます。一部のブラウザーは新しい機能を迅速にサポートしますが、他のブラウザー（Microsoft Edge / IE、咳咳）は決してそれを採用しない可能性があるため、フロントエンド開発者は常にこれに対処する必要があります。基本に固執することで、プロジェクトの将来性を保証できます。これにより、アップグレードまたはリファクタリング時に対処する必要のある変更の数が、そうでない場合よりも少なくなります。

時間の経過とともに複数の開発者を検討する

これは一種の技術的負債であり、大規模なチームは小規模な開発チームよりも時間の経過とともに発生する傾向があります。小さい方でも気にする必要がありますが。ご覧のとおり、ソフトウェアエンジニアごとにコードの記述方法が異なります。まったく同じコードで同じ問題を解決する2人の開発者がいることはめったにありません。それらは同じ機能を実行し、最終結果は同じかもしれませんが、コードは作者の声で書かれます（たとえば、Jason、Nathan、Donjete、私はすべて異なるスタイルを持っています）。コードも同じです。

そのことを念頭に置いて、ロジックの声が異なる場合もあります。ある開発者が考えていることは完全に明確であり、別の開発者はコードが何をするのかを見て、なぜそれが行われるのかわかりません。この問題は、元の作成者が相談できなくなったときに本当に問題になります。これによって発生する技術的負債は壊滅的なものになる可能性があります。しかし、それを処理する方法があります。

OldDevsの技術的負債の返済

最も簡単な方法は、可能な限り最高の開発者を雇い、決して彼らを会社から離れさせないことです。これまで。

それはほぼ100％の確率で発生することはないので、この債務の返済はあなたが思っているよりも少し簡単に軽減することができます。まず、開発チームがコードにコメントできるようにトレーニングするようにしてください。そしてそれをうまくコメントする。他の誰かによってリモートでさえ曖昧であると考えられるかもしれない決定をするときはいつでも、彼らにそれをした理由と機能がどのように機能するかを書き留めてもらいます。

さらに、チームのすべての開発者がスタイルガイドまたは一連の標準に準拠していることを確認してください。 WordPress Coreには、プラグイン、テーマ、およびCoreの貢献をインラインに保つ一連のコーディング標準があり、後で他の人が問題を起こさないようになっています。 Airbnbには、業界全体の非公式標準として採用されているReactのスタイルガイドがあります。内部のスタイルガイドや標準でさえ、開発者が自分で行き過ぎないようにします。なぜなら、それらの種類のコミットは、嗅ぎタバコをしなければマージされないからです。

まとめ

技術的負債は非常に現実的な問題です。それを管理する方法を知っていれば、それは非常に現実的なリソースでもあります。技術的負債をいつ引き受けるか、そしてそれをどのように返済するかを決定できることにより、開発は他の方法よりも迅速かつスムーズに進むことができます。そして、その負担が避けられない時代に、他の方法よりも影響を少なくするために実装できる戦略のアイデアをいくつか提供できれば幸いです。

プロジェクトおよび開発チーム内の技術的負債をどのように処理しますか？

Andrey Suslov /shutterstock.comによる記事特集画像