技術的負債を処理することでどのような見返りがありますか？
これ 技術的負債に関する記事 には、次のようないくつかの良い点があります。
「技術的な問題」への取り組みは、ストーリーによって推進される場合に最も効果的です。コードベースはおそらくどこでも作業が必要ですが、見返りは、ユーザーが直面する理由のためにコードが処理される予定の場所でのみ受け取られます。ストーリーが壊れやすいエリアを通過しない場合、その作業はほとんど無駄になります。
したがって、私はいつものようにストーリーをとる（しかし、おそらくその数は少ない）アプローチを好み、キャンプ場をあなたが見つけたよりも上手に離れるという「ボーイスカウトのルール」に従います。言い換えれば、ストーリーが私たちを導くところはどこでも、より多くのテストを書きましょう、もっと積極的にリファクタリングしましょう。
このアプローチには、少なくとも次の利点があります。
- ストーリーの「最良の」フローを維持します。
- チームのすべての才能からの支援を提供します。
- チーム全体がコードをクリーンに保つ方法を学ぶことができます。
- 改善が必要な場所に正確に焦点を当てます。
- 「必要」かもしれない改善を無駄にしない;
コードの品質が長期的な生産性に非常に大きな影響を与えることを確認したので、技術的な負債を処理する必要があると私は信じています。上記の投稿は理にかなっていると思いますが、最後の2つの点についてはよくわかりません。ユーザーストーリーに関連していなかったとしても、技術的負債のクリーニングから得られるメリットの実際の経験を見つけることに興味があります。
コードベースをクリーンアップし、技術的な負債をなくすことで、どのようなプラスのメリットを見ましたか？作業を完了するためにどの方法を使用しましたか？
私の経験から一例を挙げましょう。
10年か12年ほど前に、私は開発者のチームからアプリケーションを引き継ぎ、会社を辞めてしまいました（ここに入るには長すぎます...）。このシステムは、大規模な自社開発ミドルウェアレポート生成システムでした。毎週夜に実行され、フォーチュン500企業の上級幹部向けに約20のExcelレポートを生成しました。私がそれを継承したとき、実行するのに約5-6時間かかり、どの週でも少なくとも2泊は失敗しました。
私はこの混乱を与えられて幸せなキャンピングカーではありませんでした。
当初、私の計画は出血を止めて失敗の主な原因を修正することでした。コードベースに慣れてきたら、リファクタリングして安定性とパフォーマンスを追加できる場所を探し始めました。 2年ほどの間に、システムに多くの変更を加えました。私たちは数年前にそのシステムを廃止し、その時点でプロセス全体の実行には45分かかり、何年も問題は発生していませんでした。
技術的負債の返済に多くの労力が費やされましたが、それだけの価値はありました。システムが故障したのは、真夜中に電話を受けられなかったのは素晴らしいことでした。修道士のオフィスに来て、ログで良いニュースしか見られなかったのはニースでした。
（余談ですが...数年後、私はこのシステムの主要な開発者の1人に遭遇しました。彼はそれがどのように機能しているかを尋ね、システムがいかに悪いかを彼に話しました。彼は実際に謝罪し、それが彼が去って、彼がその上でより良い仕事をしたいと思った後、一握りのサポートをしました。
コードのクリーンアップの利点は、クリーンアップが行われていないコードを維持しなければならないときに最も顕著になるというのが私の経験です。クリーンアップが行われた場合、私の変更は、コードを読んで、変更する必要がある1つまたは2つの場所を特定し、そこから変更することです。クリーンアップが行われていない場合は、コードを数回読んで、作成者（時には私）がコードを書いたときに何を考えていたかを理解するための最初のステップを追加します。
技術的負債をなくすことで、技術サポートが減り、機能強化の基盤が改善されます
常に
私の経験の1つは、以前の雇用主でサイトパフォーマンスチームを管理していたときでした。ボットがサイトから情報を迅速に取得するため、私のチームが監視していたウェブサイトは、毎晩1時間から2時間の間、許容可能なパフォーマンスしきい値を下回りました。チームがこれに対処するために取った対策は、手動の管理システムにログインし、問題を引き起こしていたIPアドレスをブロックすることでした。言うまでもなく、これはチームのメンバーの1人にほぼ毎晩の睡眠時間を要しました。私は何が起こっているのかに気づき、オンコールのBlackBerryを数日間自分で使って、それがどれほどひどいかを確認し、チームに少し休ませました。
数日後、私は単にチームのビジネスオーナーのところに行き、ボットがサイトのパフォーマンスに影響を与えるのにはるかに困難な時間を費やすような自動ブロックシステムを実装しなかった場合、私たちは失う可能性があることを伝えました疲労と燃え尽きのために、チームメンバー全員ではないにせよ、一部のメンバー。彼らは同意し、私たちは夜に眠ることができるシステムを実装しました。事業主は、数日または1週間の開発コストが、新しいエンジニアの採用/トレーニングのコストと比較して最小限であることを理解していました。
技術的負債を返済した結果として組織が受ける最大のメリットは、複利を回避することです。以下のブログエントリには、技術的負債の元本がわずか5年間で16万ドルから43万ドルにどのように増えたかを示す例があります。その額の借金の返済に専念する専任のプログラマーが必要になります。それは意思決定者の視点に立つのに役立ちます！
最後の2つの点について：彼の 元の投稿 で説明されているように、それがどこから来ているのか理解しています。
または、一部の開発者を再割り当てしてこれらの技術的な問題を解決することは可能ですか？これはチームの速度に影響を与える可能性がありますが、何ですか？
「だから何が」と等しい：製品の所有者と他のビジネス側の人々は不満になります。そして、ママが不幸であるとき、誰もが不幸です。
それでも、実行する必要があることと実行できることとの間の境界線はかなりあいまいです。ユーザー向けは非常に幅広く、パフォーマンスとエラーの発生が含まれます。しかし、場合によっては、パフォーマンスの低下とエラーの発生率が高いという根本的な問題は、コードのより深いところにあります。彼の言葉でそれを言うと、ストーリーは無茶苦茶なエリアを通過しないかもしれませんが、その無茶苦茶なエリアは、その隣のクリーンアップされたパスでストーリーを攻撃するいくつかの厄介なものを隠すことができます。
全体的なパフォーマンスに影響を及ぼさないものは、クリーンアップすることにはあまり興味がありませんが、それらのポイントの影響を非常に注意深く評価する必要があります。多くの場合、彼らはかなりの影響を与える可能性のある間接的な影響力を持っています。