TDDとコードレビューをスキップするというとてつもないコスト

お金の色—クリス・ポッター(CC BY 2.0)

2019年1月26日更新:「生産時のバグを修正するのに設計時にバグを修正するよりも100倍のコストがかかる」という主張は不明確であることに気付きました。私は今でもTDDのROIと時間を節約する力に賛成していますが、これは科学的事実ではなく主観的な意見として読むべきです。私たちの業界は、TDDやその他の品質管理対策の影響に関するより良いデータ収集を大いに必要としています。これは、大学と大規模なソフトウェア組織の間の共同研究にとって大きなテーマになるでしょう。

近年、テスト駆動開発(TDD)の利点について話し、より生産的な品質プロセスを実装する方法に関するアドバイスを共有するように依頼する企業が増えています。

TDDは、実装を作成する前にコードが機能することを確認する自動テストを作成するプロセスです。テストを書き、失敗するのを見て(赤)、実装を書き、テストの合格を見る(緑)、必要に応じてリファクタリングします。システムを構築しながらサイクルを繰り返します。

このプロセスは徹底的に研究されており、ソフトウェアの品質を高めるのに非常に役立つことが証明されています。しかし、組織の時間と費用を大幅に節約できることをご存知ですか?

マネージャーがTDDを実装するのに長い間待つことを挙げている主な理由の1つは、コストです。 TDDを使用すると、最初のプロジェクトのビルドアウトに最大30%時間がかかるのが一般的です。

これらのマネージャーが知っておく必要があるのは、TDDが生産バグ​​密度を40%から80%削減し、それがすべての違いを生むということです。本番環境のバグが増えると、保守コストが劇的に上昇します。

再作業、メタ作業(作業に関する作業)、責任の引き継ぎ、中断、そして最終的には顧客サポート、バグのトリアージ、およびメンテナンスのコストが指数関数的に増大するため、生産バグの修正には設計時のバグ修正よりも100倍の費用がかかる場合があります、実装時にバグを修正するよりも15倍以上多くなります。

注:この主張には異議が唱えられていますが、ソフトウェアの品質が開発者の生産性を向上させることは間違いありません。ソフトウェア品質に関する利用可能なデータ、およびソフトウェア品質が組織に与える影響の詳細については、「ソフトウェア品質の経済性」を参照してください。開発チームを運営する方法について、十分な情報に基づいた意思決定を下せるように、ソフトウェアの品質測定に関するさらに多くの研究が必要です。

バグ修正の相対コスト

これらの数値を使用して、TDDを使用した場合と使用しない場合の架空のプロジェクトの相対的なコストを見てみましょう。このプロジェクトには、TDDを使用せずに1,000時間の先行導入が必要になりますが、メンテナンスは含まれません。

架空の例では、623人時間、または4人のチームで約1か月の開発時間を節約しました。各デベロッパーに米国の全国平均($ 95k)を支払い、給与に加えて平均30%を考慮して給付をカバーすると、ほぼ$ 37,000 USDの節約になります。

もちろん、これは多くの仮定を行う架空の例です。マイレージは、TDDでのチームの経験、他の品質基準(コードレビューなど)の有無など、多くの要因に基づいて異なります。

前提条件は次のとおりです。

  • TDDを使用しない生産上のバグ:100
  • TDDの生産バグ:40(60%少ない、40%から80%の中間)
  • 実装時のバグ修正(TDD)フェーズの平均時間:1時間(この数値は、実動バグ修正コストの導出にのみ使用されます)
  • 本番バグを修正するための平均時間:〜15時間

これらの変数のいずれかを使用すると、明らかに結果が変わります。かなり確実なことは、メンテナンスコストが考慮されるため、TDDが時間とお金を節約することです。多くの時間とお金です。

この架空の例の相対的な結果は、TDDを使用した場合と使用しない場合の両方で、実際のプロダクションプロジェクトでの経験に基づいて当てはまります。

コードレビューにも同様の効果があります

コードレビューにも同様の効果があります。実際、一部の研究では、コードレビューがTDDよりも効果的であることが判明しています。 1988年の調査によると、コードレビューに費やす1時間ごとに、メンテナンスで33時間節約できます。

これは非常に驚くべきことですが、コードレビューのバグをキャッチする利点は、私の個人的な経験とは異なります。自動テストはバグを見つけるのにはるかに便利だと思います。コードレビューの並外れた効果をどのように説明したらよいでしょうか。

知識共有。コードレビューを採用すると、開発者がアンチパターンやその他の貧弱なプラクティスを使用しているときに、チームが自己修正します。同時に、効果的なパターンを共有し、物事を行うためのより良い方法を互いに教え、より読みやすいコードを書く方法を互いに教えています。

その最終的な結果は、ジュニア開発者がチームで最も優秀な開発者のレベルに急速に上昇し、チーム全体の速度が向上することです。チームのメンターシップカルチャーの価値を誇張することは困難です。

中断のコスト

生産のバグを修正するのにそれほど費用がかかるのはなぜですか?バグが実稼働に到達すると、そのコストはバグを修正するための単純なコストよりもはるかに大きいためです。

本番環境でのバグ修正は、開発中のバグ修正よりもはるかに高価です。違いの大きさを理解するには、まず開発者を中断するコストを理解する必要があります。

生産バグの修正は、機能開発のコンテキストとリズムの中断を頻繁に意味します。言い換えれば、開発者は現在作業しているコンテキストから引き出され、バグのコンテキストにダンプされます。関連するコードとフローを吸収し、根本原因を診断し、バグを修正してから、彼らが以前取り組んでいたことの文脈を再吸収する。

コンテキストの切り替えごとに最大20分の開発者の生産性がかかりますが、止まることはありません。バグを修正するために開発者を中断すると、中断される前に作業していたコードに多くのバグが発生する可能性があります。 Microsoft Researchによると、中断されたタスクの完了には約2倍の時間がかかり、中断されていないタスクの2倍のエラーが含まれています。

つまり、実稼働環境でリリースされるバグを修正するコストは、実稼働環境のバグを修正するコストだけではありません。中断は、現在の開発作業のコストを増加させ、最終的に修正が必要になるバグをさらに導入します。

関連するメモでは、マルチタスクは本当に悪い考えです。生産性を高めるには、開発者は一度に1つのことに集中する必要があります。

結論

次回誰かがTDDやコードレビューの時間や予算がないと言ったら、「その場合、TDDをスキップする時間も予算もない」と自信を持って伝えてください。

次のステップ

TDDとソフトウェア開発プロセスにおけるTDDの役割について理解を深めてください。

  • 「TDDおよびユニットテストに関する5つの一般的な誤解」
  • 「ユニット対機能対統合テスト」
  • 「ユニットテストごとに答えなければならない5つの質問」
  • 「ES6のTDDおよびReact Webキャスト」
  • メンターシップでチームをレベルアップする:よりテスト可能なコード、TDD、CI / CDプロセスなどを記述する方法

ライブ1:1メンターシップでスキルをレベルアップ

DevAnywhereは、高度なJavaScriptスキルをレベルアップする最速の方法です。

  • ライブレッスン
  • 柔軟な時間
  • 1:1のメンターシップ
  • 実際の本番アプリを構築する
https://devanywhere.io/

エリックエリオットは「プログラミングJavaScriptアプリケーション」(O’Reilly)の著者であり、DevAnywhere.ioの共同設立者です。彼は、Adobe Systems、Zumba Fitness、The Wall Street Journal、ESPN、BBC、およびUsher、Frank Ocean、Metallicaなどのトップレコーディングアーティストのソフトウェアエクスペリエンスに貢献しています。

彼は、世界で最も美しい女性と、どこでも好きな場所で仕事をしています。