「このマニュアルでは、レガシーコードをリファクタリングできません！」一般的な状況？ひどく迷惑です。ほとんどの開発者は遅かれ早かれ、すでに準備ができているものを改善することにまったく興味がないマネージャーに直面します。彼らは何か新しいものを実装するか、緊急に火を消すか、いくつかのバグを修正する必要があります...一般に、実行中のコードベースのリファクタリングを延期する理由を常に見つけます。
そして、あなたが彼らにきちんとしたコードの利点を説明しようとしても、彼らは理解していないか、理解したくないのです。彼らは彼らの心にコストと期限があるだけで、誰も品質を気にしません。そして、あなたは技術的な負債について何かをすることは絶対に無力であることがわかりました。それはまだ蓄積され続けています。プログラマーはprodのために働き、prod-せっかちなユーザー要求のために働きます。誰もリファクタリングにお金を払うことはありません。状況は絶望的に見えます。
このような状況では、多くの賢い開発者は単に荷物をまとめて会社を辞めます。そしてすぐに、部門の交代のために、ドアはもはや閉じられていません：いくつかは去り、他は来る...
マネージャーはプログラマーではありません
この問題の解決策は、コード品質の低下がビジネスに与える影響をマネージャーに伝えることです。最終的に、会社の活動はお金を稼ぐことを目的としています。到着した。したがって、経営陣はコストを削減し、収益を上げるための最良の方法を探しています。これは、彼らの目のリファクタリングをリハビリするために、彼らは彼らの言語を話さなければならないことを意味します。
私はたまたまテクニカルリードとコンサルタントの両方を務めていたので、このビジネスで多くの経験があります。いくつかのテンプレートを共有しましょう。
あなたが与えることができる5つの議論
1）「リファクタリングはソフトウェア機能の単位あたりの限界コストの変動を減らすのに役立ちます」
これは、会議「ソフトウェア開発の経済学」でのJBReinsbergの優れた講演からの正確な引用です。待って、行かないで！ここで言われていることはすべて、あなたは完全によく知っています、それは単に抽象的な、乱暴な精神で定式化されています。
順番に行きましょう：
- 「リファクタリングは削減に役立ちます...」-これまでのところ、すべてが順調です
- 「...ボラティリティ...」-言い換えれば、予測不可能
- 「...限界コスト...」-つまり、別の追加ユニットを作成するために必要なリソースの量
- 「…ソフトウェア機能の単位あたり」は、ビジネスに価値のある機能です。やったー！ビジネス価値はまさに私たちが必要としているものです。
5つの議論はすべて、ある言語から別の言語への翻訳という同じ一般的な考え方に基づいています。これは、IT分野から遠く離れた人々とのやり取りではしばしば無視されます。スラングを使用しないでください。経済学とビジネスの概念に頼ってください。それが秘密の要素です。これにより、管理者との接続をより迅速に確立できます。
2）「この1か月間、開発リソースの63％が製品の品質の問題の修正に費やされました」
そうですね、ここで数値を置き換えてください。重要なのは、定量的なデータでメッセージをバックアップすることです。技術債務は、日々の作業プロセスに影響を与えずにはいられません。証明できますか？もちろん！
確認できる指標は次のとおりです。
- . ? ?
- -, , . , ? ?
- , . ? ?
悪いコード品質が彼らにとってどこに変換されるかを正確に管理者に示してください。さらに良いことに、これらの数値を金銭的価値に変換する方法を見つけてください。
私はかつて、データタイプのチェックが実行されていれば回避できたであろう死後のバグに参加しました。コードはJavaScriptで書かれています。当時、TypeScriptに切り替えるかどうかについて社内で議論がありました。
何が起こったのかを理解した開発者は、データを上げるのに怠惰ではなく、バグがビジネスにもたらした損害を評価することができました。その存在の数ヶ月で、バグは会社から百万カナダドルを吸い込んだことが判明しました。百万！ TypeScriptに切り替えるコストを相殺するには、それだけで十分でした。
これに基づいて、新しいサービスをTypeScriptで実装することが決定されました。最も重要なサービスについては、データタイプをさかのぼって確認する必要があります。
3）「技術的な観点から、私たちは製品をより早く発売するためにクレジットに取り組みました。今、私たちは、市場投入までの時間が増加しないように、負債の一部を完済する必要があります。」
繰り返しますが、私たちは対話者の言葉を話します。メタファーは、メッセージを伝える必要がある場合に非常に効果的です。メタファーは、聞き慣れない概念をリスナーにとってなじみのある概念と結び付け、理解するのに役立ちます。 「クレジット」の概念は、どのマネージャーにもよく知られています。そして、「技術的負債」自体も、広く流通している比喩です。
または、たとえば、会社をレストランとして、コードベースをキッチンエリアとして想像してみましょう。汚れた皿がたまるにつれて、ますます多くの訪問者にサービスを提供することはますます困難になります。従業員は料理の合間に皿を洗う時間が必要です。
4）「作業時間の10％をコード品質に投資すると、売上高は大幅に低下します。」
これまで、コード品質の低下による明らかな結果について説明してきました。しかし、見落としがちな陰湿なことが1つあります。それは、売上高です。
最近の企業は、開発者、特に才能のある開発者を維持するのに苦労しています。そのような人が仕事を楽しむのをやめたとしても、彼が別の申し出を受けて、永遠の混乱から離れて、どこを見てもただ行くことは難しくありません。しかし、そこには何がありますか、おそらくあなた自身はすでに何かより良いものを探しています...
そして今、私たち自身に質問をしましょう：会社は引退した開発者を置き換えるのにいくらかかりますか？新しいスペシャリストを見つけ、採用プロセスをウォークスルーし、最新の状態にする必要があります。それには投資と時間がかかり、チーム全体が保留になります。経営陣は間違いなく、この種の再シャッフルを毎年行わないことを望んでいます。したがって、流動性を減らすことは深刻な議論になる可能性があります。そして、技術的な負債をなくす計画を立てているという事実は、チーム全体にすぐに+100のモチベーションを与えます。
5）「リソースの20％をリファクタリングに投資すると、FRTは半分に削減され、ROIは開発者の生産性にプラスになります」
FRTは応答時間であり、ユーザーサポートの重要な指標です。ビジネスは、顧客がすべてに満足することを保証するよう努めています。
ここでは、次のことを行います。
- 技術サポートに大きな重みを持つメトリックを選択する。
- 定期的に発生し、開発者の介入が必要な問題がいくつか見つかりました。
- 根本原因を排除することにより、テクニカルサポートへの問い合わせ回数を減らす計画を提供します。
- このような問題が解決されれば、開発者はユーザーサポートタスクに関与する可能性が低くなります。つまり、リファクタリングに費やされた時間よりも多くの時間を解放できます。つまり、投資が報われるということです。これは非常にプラスのROIです。
最終的に、彼らは決定します
誰もそれについて議論することはできません。技術的な負債をなくすことの重要性を人々に納得させるために5つの議論をしましたが、マネージャーに就職する前に、もう1つアドバイスが必要だと思います。
移動しながらリファクタリング
リファクタリングは、機能に関する作業の別個のフェーズと見なされるべきではありません。結局のところ、将来どの機能が実装されるかを事前に予測することはできません。これは、新しい現実が利用可能になったときに、コードベースを調整する必要があることを意味します。これは、その非常に重要な価値を生み出すために必要な作業の一部でもあります。プロの開発者なら誰でもこれを確認できます。
このルールは、レガシーコードを使用するデータベースでも機能します。ええと、明日までに彼女を神の形にすることは絶対にありません。また、その間に大規模なリファクタリングを実行しようとすることも、致命的な問題です。しかし、このアプローチでは、少なくとも状況は悪化しません。また、lrgacyコードを使用する場合は、「良い」ではなく「より良い」に焦点を当てる必要があります。
バグを修正していますか？自動テストの作成にさらに1時間を費やします。新機能を展開する準備はできていますか？コードをクリーンアップするために余分な日を取ります。毎日痛みのない変更を行うようにしてください。数か月後、この習慣が生産性に大きな影響を与えていることに気付くでしょう。なぜなのかご存知ですか？リファクタリングは、ソフトウェア機能の単位あたりの限界コストの変動を減らすのに役立つためです。