I.はじめに
昨年のこの頃、仕事の取り決めに端を発する技術的負債の問題について真剣に議論することを考えました。
このシステムは3年以上運用されており、事業の発展に伴い、ますます多くの事業者や事業者とつながり、次々と重要性を増しているため、事業者側もより高い提案を行っています。制度の基準を聞いたところ、部長の同級生がすぐに制度を引き継ぐように手配されたのですが、同級生から強い不満があり、当時、これまで懸命に取り組んできた服従の取り決めがどうしてそうなったのか疑問に思いました。強い感情？結局のところ、それはこの歴史よりも私たちの手にある古いシステムがたくさんあるので、私は状況についてもっと学ぶことにしました。
当時、古いテクノロジースタック、一貫性のないインターフェイス、コードの冗長性、一貫性のないコードスタイル、不合理な設計、コア機能のパフォーマンスの低下など、いくつかの大きな問題があると分析されました。これらは一般的な問題ですが、これのパフォーマンスシステムはより深刻です。問題を分析した後、私はシステムの現在の開発、元開発者、および元開発者を開始することを決定し、当時と思われるいくつかの主要な問題を解決するために夜間に残業を使用する著名なチームを設立しました。 3週間近くかかりました。プロセスは曲がりくねっていましたが、効果は明らかではありませんでした。今年、システムに別の品質問題を引き起こし、製品の運用と保守の増加につながるいくつかの隠れた危険があります。
莫大な技術的負債は、ソフトウェア開発チームの生産性に影響を与え、彼らの士気と熱意を低下させます。技術的負債の継続的な蓄積は悪循環につながります。巨額の技術的負債は生産効率とチームのモラルを低下させます。同時に、生産効率が低いとマネージャーはより多くの機能を起動し、技術的負債の問題を拡大し、技術的負債をさらに増加させます。 。
情報化とインターネットの発達に伴い、古いシステムと技術的負債の管理は、私たちベテランが直面している問題です。
2.技術的負債とは
有名なコンピュータープログラマーのウォードカニンガムは、1992年にいくつかのソフトウェアシステムの混乱を最初に借金と比較しました。
最初のコードを提供することは、借金をするようなものです。債務は開発をスピードアップすることができ、コードを書き直して債務を期限内に返済することによってのみ可能です。債務が返済されない場合、危険が発生します。間違ったコードを書くのに費やされた毎分は、借金の利子としてカウントされます。マージされていないコード展開、オブジェクト指向設計、またはその他の債務問題により、ソフトウェアプロジェクト全体が停止する可能性があります。-ウォードカニンガム（ウォードカニンガム）
これは金融債務と非常によく似ています。個人または組織が急速な発展のために金融機関からローンを取得する場合、価格は元本に加えて利息を追加することです。彼が定期的に返済することができれば、彼が負っている債務は許容可能であり、それ以上の問題を引き起こすことはありません。彼が返済しなかったり遅れたりした場合、彼は利息で罰せられます。不払いの数が増えると、ペナルティ利息も増加し、債務の累積により破産する可能性があります。
カーネギーメロン大学ソフトウェアエンジニアリング研究所（SEI）のRobert Nordは、「技術的負債の管理の未来」で「技術的負債の展望」の概念を提唱しました
（図1：Robert Nordから「技術的負債の管理の未来」）
技術的負債のパノラマは、主に保守性と進化可能性の2つの方向から、ソフトウェアシステムに対する技術的負債の影響を分析します。同時に、問題の可視性と組み合わせて、ソフトウェア開発プロセスに対する技術的負債の影響を分析します。
技術的負債のパノラマは、可視性の観点から技術的負債の範囲を分析します。たとえば、欠陥や実装されていない機能は、ソフトウェア製品の価値に明らかに影響し、一般に迅速に解決できるため、技術的負債とは言えません。技術的負債は目に見えない部分です。 、不合理なアーキテクチャ設計、貧弱なコード品質、テストやドキュメントの欠如など。欠陥はしばしば技術的負債の兆候です。
さらに、技術的負債をよりよく理解するために、SEIの研究者は、技術的負債の実用的な定義とコアコンセプトについて話し合い、システム、機能、欠陥、症状、独創性、推論、ソフトウェアの成果物、およびコンテキストの関係について説明しました。
（図2：技術的負債の概念モデルはRobert Nordの「技術的負債の管理の未来」から来ています）
3.技術的負債の構成
多くの人は技術的負債を聞くと幻滅します。金融債務と同様に、技術的負債は必ずしも悪いことではありません。借金は私たちがお金を稼ぐ前に投資する資本を私たちに与えます。製品を市場に出すときに近道をとることで、ビジネスモデルを低コストでテストし、コードが適切でないとわかったときにコードを破棄することができます。
通常、技術的負債の導入は、ソフトウェア製品をより短い時間で提供することであり、それによってアーキテクチャ、コード、テスト、およびドキュメントに妥協をもたらし、ソフトウェア製品がユーザーに到達し、できるだけ早くフィードバックを得ることができるようにします。これの最大の利点は、より完璧な設計とドキュメントではなく、ソフトウェア製品を迅速に実行できるようにすることです。結局のところ、ユーザーは使用可能なソフトウェア製品を見たいと思っており、内部のデザインや品質は気にしません。これは特にCエンドユーザー向けに開発された製品に当てはまります。時は命であり、より早く市場に出る可能性があります。生き残ることによって、次のステップの余地がありますか。
ソフトウェア開発のゴッドファーザーである「リファクタリング」と「エンタープライズアプリケーションアーキテクチャパターン」の著者であるマーティンファウラーは、技術的負債によって生み出される関心は、急いで設計を決定するため、将来の研究開発にもっとお金を払う必要があることを示していると考えています。技術的負債に直面しても、利益は継続的に支払うことも、復興を通じて一括で支払うこともできます。コードの悪臭は技術的負債でもあり、問題を悪化させる一種の無謀な負債であり、技術的負債を象限に分割します:(
図3：マーティンファウラーの「技術的負債象限」の技術的負債象限」》）
技術的負債が導入された理由として、SEIの調査によると、ほとんどの開発者はアーキテクチャの選択を検討しています。アーキテクチャの選択とその設計への影響は何年も続くことが多く、計画や改造が難しく、改造のコストが非常に高くなります。
（図4：ニールアーンストの「技術的負債のフィールド調査」からの自由形式の質問のコーディング頻度）
技術的負債にはさまざまな種類があり、1,000人の開発者が1,000人のハムレットを所有しています。このため、SEIの研究者は調査を実施し、アーキテクチャの選択が不十分、コードが複雑すぎる、コードのドキュメントが不足していることが、技術的負債の3つの最も一般的なタイプであることがわかりました。
（図5：ニールアーンストの「技術的負債のフィールド調査」からの技術的負債のソースのランキング）
4.技術的負債の管理方法
ほとんどの事業開発シナリオでは、ソフトウェア開発チームが顧客に迅速に価値を提供する責任があります。技術的負債は避けられないため、技術的負債の管理はすべての実務家が直面しなければならない問題であり、勤勉で実践的な態度を取ります。負債は非常に重要です。
チームのコンセンサスが技術的負債を防ぐ
The Code and Rapid SoftwareDevelopmentの著者であるSteveMcConnellは、技術的負債を、チームに関連する2つのカテゴリ（意図的でないものと意図的なもの）に分けています。
1）意図しない技術的負債：経験不足のために低品質のコードが作成されました。
2）意図的に発生した技術的負債：現在の状況によっては、設計と選択によって現在の問題を迅速に解決できる場合があり、場合によっては厄介になります。
人々は開発チームの技術的負債を理解しています。開発チームは、技術的負債、そのさまざまな側面と種類、およびプロジェクトに対する負債の影響を理解する必要があります。技術的負債を全員に理解してもらい、技術的負債を可視化し、習慣を身に付け、定期的にコミュニケーションと交渉を行うようにしたい場合。
Mathias Verraesは、記事「技術的負債の壁：技術的負債を隠す場所をなくす」で、チームが作業する壁を提案し、それが一般に公開されていることを確認して、「技術的負債の壁」とラベル付けしました。美しく鮮やかなロゴを描き、付箋紙やマーカーが周りにあることを確認します。
（図6：技術的負債の壁はMathias Verraesによる「技術的負債の壁」から来ています）
技術的負債を返済するためのプロセスサポート
雇用関連のプロセスは、開発チームが技術的負債の蓄積を回避するのに役立ちます。このような方法の典型的な例は、レビュープロセス（コード、設計、アーキテクチャ、テストレビューなど）とアーキテクチャ管理（コードが期待されるアーキテクチャと設計に準拠していることを確認するなど）です。ただし、使用するプロセスは実用的である必要があります。頑固でプロセスに従うのが難しいと、チームはそれらを完全にフォローできなくなり、永続化のプロセスでショートカットを探すようになります。
技術的負債の蓄積は、プロセスからのみ回避することはできません。ライアンDは、記事「技術的負債を修正するために機能の出荷を停止する必要はありません」で、すべてのタスクを分類し、少なくとも機能の改善と計画されたタスクに分割する必要があると提案しました。 、配送能力と計画外の作業。作業をこれらの4つの領域に分類することにより、作業の価値を伝えやすくなり、技術的負債の問題に対処するための時間を解放しやすくなります。そして、上記の4つのカテゴリーに合理的に時間を割り当て、利害関係者と一緒に正しい時間配分比率を決定します。利害関係者の参加がない場合、配分比率を正しく決定することはできません。
BMCは、スティーブン・ワッツとジョーHertvikはコラムニストの記事で技術的負債解消する6つのステップを提案している「技術的負債を：究極のガイド」：
（図7：6つのステップ：スティーブン・ワッツとジョーHertvikの「TTechnical債務から嫌なもの＆技術的負債を削除する：究極ガイド）
- 債務の記録と追跡-開発者が問題があると考えるすべてのコードと設計を記録する
- 技術的負債の分類-技術的負債をカテゴリに分類し、完了するタスクとして扱います。
- 技術的負債の影響を評価する-債務の影響を全員に知らせ、それを反復に入れるかどうかを決定する
- 技術的負債を公表する-技術的負債を公的かつ透明にする
- 技術的負債の解消を計画する-技術的負債の解消計画を利害関係者に伝え、技術的負債の解消によって新機能の提供が影響を受ける可能性があることを通知します。
- 技術的負債をできるだけ早く排除し、頻繁に-技術的負債の排除を定期的に手配する
V.まとめ
通常、チームは大量の技術的負債を蓄積したプロジェクトに取り組みます。この場合、プロジェクトの技術的破産につながる可能性があるため、債務の前払いを無視することは賢明ではありません。一方、新機能の開発を数か月間停止し、代わりに技術的負債の返済に集中することは現実的で実用的ではありません。このような状況下では、バランスの取れた開発モデルが必要であり、債務の返済は着実に行われ、機能の進歩とソフトウェアの可用性は可能な限り維持されます。技術的負債を返済する決定には、次の要素が必要です。
- 出力の速度または品質が向上します。たとえば、このビルド構成をやり直すと、配信時間が半分に短縮され、展開頻度が2倍になります。
- 遅延はコストが高くなり、スケジュールが厳しくなります。たとえば、この問題を今すぐ解決しないと、顧客、利益、または収益に直接影響します。
6、参照リソース
- BMCブログ：技術的負債：究極のガイド-Stephen Watts、Joe Hertvik
- SEIインサイト：技術的負債のフィールド調査-ニールアーンスト
- SEI Insights：技術債務管理の未来-Robert Nord
- SEI Insights：機械学習による技術的負債の議論の自動検出-Robert Nord
- SEIインサイト：技術的負債の結果の管理-Ipek Ozkaya
- 技術的負債-マーティンファウラー
- 技術的負債象限-マーティンファウラー
- 技術的負債の壁：技術的負債を見えなくする-Mathias Verraes
- 実用的な技術的負債管理-TusharSharma
- 技術的負債はテトリスのようなものです。コードを変更して修正するにはどうすればよいですか？-エリック・ヒギンズ
- 機能の提供を止めることはできませんが、残りの技術的負債の問題をどのように解決するのですか？-ライアンD
私たちに関しては
戦闘やその美しさにおいてどれほど強力であっても、十分な教育を受け、思慮深く、原理的なチームです。
著者：WangYun-中年の農民の余分な手荷物の無能なコード