技術的負債に関するこの記事には、次のような優れた点があります。

「技術的な問題」に取り組むことは、ストーリーによって推進されるときに最も効果的です。コードベースはおそらくどこでも作業を必要としますが、ユーザーに面した理由でコードが作業される場所でのみペイオフが受け取られます。ストーリーがなかなか難しい領域を通過しない場合、その作業はほとんど無駄になります。

したがって、私はいつものように（しかしおそらくそれよりも少ない）物語を取り上げ、あなたが見つけたよりもキャンプ場を去るという「ボーイスカウトのルール」に従うアプローチを好む。言い換えれば、ストーリーが私たちを導くところはどこでも、より多くのテストを書きましょう、より積極的にリファクタリングしましょう。

このアプローチには、少なくとも次の利点があります。

• 「賢明な」ストーリーの流れを維持します。
• チームのすべての才能からの支援を提供します。
• チーム全体がコードをクリーンに保つ方法を学習できるようにします。
• 改善が必要な場所に正確に焦点を合わせます。
• 「必要な」改善を無駄にしない;

コードの品質が長期的な生産性に非常に大きな影響を与えるのを見てきましたので、技術的な負債を処理する必要があると考えています。上記の投稿は理にかなっていると思いますが、最後の2つのポイントについてはよくわかりません。たとえユーザーのストーリーに関係していなくても、技術的な負債を取り除くことで得られるメリットの実際の経験を見つけることに興味があります。

コードベースを整理し、技術的な負債をなくすことで、どのようなプラスのメリットがありましたか？仕事を成し遂げるためにどのような方法を使用しましたか？

私の経験から例を挙げましょう。

約10〜12年前、私は開発者チームからアプリケーションを継承しましたが、最終的には会社を辞めました（ここに入るには長すぎます...）。このシステムは、大規模な自家製ミドルウェアレポート生成システムでした。毎週夜に実行され、フォーチュン500企業の上級管理者向けに約20個のExcelレポートを生成しました。私がそれを継承した場合、実行に約5〜6時間かかり、特定の週に少なくとも2晩は失敗しました。

私はこの混乱を与えられる幸せなキャンピングカーではありませんでした。

当初、私の計画は出血を止め、失敗の主な原因を修正することでした。コードベースに慣れてきた後、リファクタリングして安定性とパフォーマンスを追加できる場所を探し始めました。2年ほどの間に、システムに多くの多くの変更を加えました。数年前にこのシステムを廃止しましたが、その時点でプロセス全体の実行に45分かかり、何年も問題は発生していませんでした。

多くの作業が技術的負債の返済に費やされましたが、それは十分に価値がありました。真夜中にシステムに障害が発生したため、電話がかかってこなかったのは良かったです。月曜日にオフィスに来て、ログで良いニュース以外は見られなかったのはよかったです。

（さておき...数年後、私はこのシステムの主要な開発者の一人に出会いました。彼はそれがどのように機能しているかを尋ね、私は彼にシステムがどれほど悪いかを伝えました。彼が去り、彼がそれでより良い仕事をしたことを望んだ後にサポートするほんの一握り）。

クリーンアップが行われていない場所でコードを維持する必要があるときに、コードクリーンアップの利点が最も顕著になるのは私の経験です。クリーンアップが行われた場合、私の変更は、コードを読み、変更する必要がある1つか2つの場所を見つけて、そこから進むことです。クリーンアップが完了していない場合は、コードを数回読み取り、作成者（場合によっては私）が書いたときに何を考えていたかを把握しようとする最初のステップを追加します。

技術的負債を排除することで、技術的サポートが少なくなり、改善のためのより良い基盤が得られます

常に

私が経験したことの1つは、以前の雇用主でサイトパフォーマンスチームを管理していたときでした。毎晩1時間から2時間、私のチームが監視していたWebサイトは、ボットがサイトから情報を迅速にスクレイピングするため、許容可能なパフォーマンスのしきい値を下回りました。これに対処するためにチームが講じた対策は、手動管理システムにログインし、トラブルを引き起こしていたIPアドレスをブロックすることでした。言うまでもなく、これにはチームメンバーの1人がほぼ毎晩睡眠時間を要しました。何が起こっているのか気づいたので、数日間自分でオンコールのBlackBerryを取り、それがどれほど悪いのかを確認し、チームに休息を与えました。

数日後、私は単にチームのビジネスオーナーに行き、ボットがサイトのパフォーマンスに影響を与えるより困難な時間を持つように自動ブロックシステムを実装しなかった場合、失う可能性があることを彼らに知らせました疲労と燃え尽きによるチームメンバー全員ではないにしても、一部。彼らは同意し、私たちは夜寝ることができるシステムを実装しました。ビジネスオーナーは、開発の数日または1週間のコストが、新しいエンジニアの採用/トレーニングのコストと比較して最小限であることを理解していました。

最後の2つの点について：彼の元の投稿で説明されているように、私はそれがどこから来たのか理解しています：

または、一部の開発者を再割り当てしてこれらの技術的な問題を解決し、残りのチームはユーザー指向の作業を続けることは可能ですか？これはチームの速度に影響する可能性がありますが、それではどうでしょうか？

「だから何」に等しい：製品所有者と他のビジネス側の人々は不幸になります。そして、ママが不幸なとき、誰もが不幸です。

しかし、何をしなければならないか、何をすべきかの間の境界線はかなりあいまいです。ユーザー向けは非常に広く、パフォーマンスとエラーの発生が含まれます。しかし、かなりの場合、パフォーマンスの低下とエラーの高い発生という根本的な問題は、コードのより深いところにあります。彼の言葉で言うと、ストーリーはaい領域を通過しないかもしれませんが、そのcrい領域は、その隣のクリーンアップされたパスでストーリーを攻撃するいくつかの厄介なものを隠すことができます。

全体的なパフォーマンスに影響を与えないものはクリーンアップするのにあまり興味がありませんが、それらのポイントの影響を非常に慎重に評価する必要があります。多くの場合、彼らは間接的な影響をかなり受けます。

技術的負債を返済した結果として組織が受ける最大の利益は、複利を回避することです。以下のブログエントリには、技術的負債に対する元本の金額がわずか5年で160万ドルから43万ドルになった例があります。フルタイムのプログラマーが、その額の負債を処理することに専念する必要があります。これは、意思決定者にとっての見通しに役立ちます！

blog.acrowire.comから。