私の組織のソフトウェア開発チーム (API の開発 - ミドルウェア) は、一度に少なくとも 1 つのベスト プラクティスを採用しようとしています。リストには次のようなものがあります。
単体テスト (本当の意味で)、自動化された単体テスト、テスト駆動設計と開発、静的コード分析、継続的統合機能など.
どの「ベスト」プラクティスが採用された場合に ROI が向上し、ソフトウェアの品質がより速く向上するかを示す調査を教えてください。そこに研究はありますか？これは、これらのプラクティスの実装に優先順位を付けるのに役立ちます (私の主張を裏付ける)。
「どの「ベスト」プラクティスを採用した場合に ROI が向上し、ソフトウェアの品質がより速く向上するかを示す研究」
それは素晴らしいことではないでしょうか。もしそんなことがあったら、みんなでやっていて、DDJ でそれを読むだけです。
ないので、苦渋の判断をしなければなりません。
「8% の ROI のために X を実行する」ということはありません。テクニックの中には、多額の投資を必要とするものがあります。その他は無料で始められます。
ROIを知ることはできません。したがって、投資を優先することしかできません。人々が他のものよりも採用しやすいものもあります。チームがこの手法を受け入れる意欲を考慮に入れる必要があります。
編集。単体テストは無料です。
「テストのコーディングに費やす時間は、リストの次の機能をコーディングするのに費やされた可能性があります」 確かに、テストは開発者がより多くの作業を行うことを意味しますが、サポートはデバッグの作業を減らします。これは1対1の取引ではないと思います。正式な単体テストの記述 (および合格) にもう少し時間を費やすことで、サポート コストが大幅に削減されます。
「レガシーコードはどうですか？」ポイントは、無料はコスト管理の問題だということです。レガシー コードに単体テストを追加すると、コストは無料ではありません。だから、それをしないでください。代わりに、メンテナンス、バグ修正、および新規開発の一環として単体テストを追加してください。その後は無料です。
「トレーニングが問題です」 私の経験では、いくつかの確かな例と、コードに加えて単体テストに対する管理上の要求の問題です。単体テストが必要であることを説明するには、全体会議以上のことは必要ありません。以下に例を示します。次に、全員が自分のステータスを「書かれたテスト/テストに合格」として報告する必要があります。60% 完了していません。315 個のテストのうち 232 個です。
「特定のプロジェクトで機能する場合にのみ、平均して無料です」常に正しい、良い点.
「もっと時間が必要です。時間はビジネスに自由ではありません」 ほとんど機能せず、多くのサポートを必要とする悪いコードを書くことも、機能するが多くのサポートを必要としない良いコードを書くこともできます。テストに実際に合格するまでの時間は、サポート、メンテナンス、およびデバッグのコストを削減すると思います。私の経験では、リファクタリングのための単体テストの価値により、アーキテクチャの変更にかかる時間が劇的に短縮されます。機能を追加する時間を短縮します。
「すぐに ROI になるとは思いません」 実際、1 つの単体テストには非常に大きな ROI があるため、特性化するのは困難です。最初に合格するテストは、あなたが本当に信頼できると思うものになります。信頼できるコードを 1 つだけ持つことで、時間の節約になります。考えるのに多くの時間を費やさなければならないことが 1 つ減るためです。
戦記
今週は、バルク データ ローダーを完成させる必要がありました。お客様から受け取った 30,000 行のファイルを検証してロードします。内部で開発したファイルをアップロードするために使用する優れたライブラリがあります。そのモジュールを顧客ファイルに使用したかったのです。しかし、顧客のファイルはかなり異なっているため、ライブラリ モジュール API はあまり適していないことがわかりました。
そのため、API を書き直し、テストを再実行して、変更をチェックインしました。これは、API の大幅な変更でした。破損多し。すべての参照を見つけて修正するために、ソースを大幅に検索します。
関連するテストを実行した後、チェックインしました。そして、密接に関連していないと思われるテストを再実行しました。おっと。失敗しました。API の一部ではないものをテストしていましたが、これも壊れていました。修理済み。再度チェックインしました（1時間遅れ）。
基本的な単体テストがなければ、これは QA で機能しなくなり、バグ レポートが必要になり、デバッグと再作業が必要になります。労力を見てください: QA 担当者がバグを見つけて報告するのに 1 時間 + 開発者が QA シナリオを再構築して問題を特定するのに 2 時間 + 何を修正するかを決定するのに 1 時間。
単体テストあり: テストが通らなかったことに気づき、コードを修正するのに 1 時間。
ボトムライン。テストを書くのに3時間かかりましたか？いいえ。しかし、テストを書くための私の投資に対して、プロジェクトは 3 時間戻ってきました。
あなたが提示したリストが一連の「ベストプラクティス」を構成していると仮定しています（ただし、おそらくそうであることに同意します）
プロセスの変更を 1 つ選択するのではなく、現在のプラクティスを調べてみませんか?
これを自問してください：
どこが一番痛いですか？それを削減/排除するために何を変更できますか?
痛みがなくなるまで繰り返します。
リストにコードレビューについて言及していません。私たちのチームにとって、これはおそらく最大の ROI をもたらしたものです (そうです、投資は高額でしたが、収益はそれ以上でした)。Code Complete (少なくとも元のバージョン) では、欠陥 VS テストを見つける際のレビューの効率に関する統計について言及されていることを知っています。
一度に 1 つの練習では、最高の ROI は得られません。プラクティスは独立していません。
単体テストと TDD に関する ROI のリファレンスがいくつかあります。この関連する質問に対する私の回答を参照してください。単体テストの ROI の明確な証拠はありますか? .
「局所最適」というものがあります。これについては、ゴールドラットの著書「ゴール」で読むことができます。イノベーションは、全体的なスループットを改善する場合にのみ価値があると述べています。新しいテクノロジーを実装する決定は、プロジェクト内のクリティカル パスに関連している必要があります。テクノロジーがすでに十分な速度でプロセスを高速化すると、準備が整ったモジュールの不要なバックログが作成されるだけです。プロジェクト開発の全体的な速度を向上させる必要はありません。
他の回答よりも良い回答があればいいのにと思いますが、そうではありません。つまり、設計上、冗長性を最小限に抑えます。言うのは簡単ですが、経験が必要です。
データでは、データを正規化したままにしておくことを意味し、それができない場合は、厳密にバインドされた通知に依存せず、ある程度の矛盾を許容できる緩やかな方法で処理することを意味します。これを行うと、コードが大幅に簡素化され、単体テストの必要性が減ります。
ソースコードでは、「入力データ」の一部が非常に遅い速度で変更される場合、ソースコードを簡素化し、パフォーマンスを向上させる方法としてコード生成を検討できることを意味します。ソース コードが単純であれば、レビューが容易になり、テストの必要性が減ります。
不機嫌になるつもりはありませんが、残念ながら、私が見たプロジェクトからは、あまりにも多くの「抽象化のレイヤー」を使用して過剰に設計する傾向が強く、それらが存在しない場合でもその正確性を疑問視する必要はありません。そこにもありません。