→脆弱性関連
→システム障害
→テストツール
→CI/CD
サブトピック†
技術的負債／リファクタリング†
- 【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ 2020
- Ward Cunninghamが当初提唱した「負債(Debt)」のメタファーと、後に一般化された「技術的負債(Technical Debt)」の捉え方の違いについて言及
- Ward Cunninghamが言う「負債」とは、ソフトウェア開発の過程で得られる知識・理解とコードとの乖離が生産性を下げることを指していた。つまり、コードの質そのものよりも、コードとチームの理解のズレに焦点があった。
- しかし、後に「負債」という言葉が独り歩きし、「技術的負債」としてコードの質の悪さ、旧来の技術の使用など、もっと広い意味で使われるようになった。
- そのため、Ward Cunninghamが本来意図した「負債」の狭い意味合いとは異なり、現在の「技術的負債」には「行き当たりばったりなコーディング」などネガティブなイメージが伴うようになった。
- 「負債」という言葉が、Ward Cunninghamの本来の狭い定義から離れ、独自の広い解釈が一般化してしまったという意味で「独り歩き」した
カバレッジ†
- テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について 2018.3
- 『カバレッジが高ければ、品質が高い』は誤った論理であり、正しくは 『「カバレッジが高い」かつ「テストケースの品質が高い」ならば、「コードの品質が高い」』 である。
- いくらカバレッジが高くても、 テストケースの品質が悪ければ、バグが潜在している可能性を低くすることはできない。
- カバレッジを100%に近づければ近づけるほど、バグ検出の費用対効果は低下する。
- クリティカルなコードではない限り、カバレッジ（C0 / C1）の目標値は 85%程度 に設定すべきである。
- NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ 2008
- カバレッジは、参考程度に見るのはいいけど、数値目標を立てて管理に使い始めると弊害が増える。
- 問題なのは、バグ密度ですよ。いまどき、「これくらいの行数なら、これくらいのバグが含まれているはずだから、その数に足らない場合はテストが足りない」なんて管理はないでしょう。「バグの数が少なかったら、無理やりバグを仕込んで数を増やす」なんて意味のない行動を引き起こすことになる。
- ユーザの立場からすると、仕様書どおりに動いていることが品質が高いということではない。多少のバグがあっても、実際に使うエンドユーザが機能に魅力があると感じて、ビジネスとして成功することが、品質の高さにつながる。
品質管理一般†
- エンジニアなら知っておきたい障害報告&再発防止策の考え方 2018
- 障害報告は始末書や反省文ではない
- 「起きた現象」の内容ではなくて、「原因やバグが発生しているモジュール名」などを書いてしまいがち
- 3段階くらいに再発防止策を検討
- 直接原因 ： その不具合が発生した直接的原因
- 間接原因 ： その不具合に至るまでの間接的な原因
- 本当の理由： なぜ、このようなパターンの障害が発生したか
静的解析/コードメトリック/コードメトリクス†
Amazon CodeGuru†
Last-modified: 2025-03-15 (土) 12:24:34
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
