天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

「Code Complete(第2版下巻)」を読んだ

Code Complete(第2版下巻)を読んだので、感想を書いていきます。

読んだきっかけ

昨年末に、Steve McConnell著のMore Effective Agileを読んだのですが、内容が実践的で学びが多く良い本でした。
Steve McConnellと言えばCode Completeで、こちらもプログラマーのバイブルとして紹介されることが多い本ですが、自分は新卒の時に何が書いてあるのか良く分からずに途中で投げ出してしまった記憶しかないので、改めて読んでみることにしました。
2週間前位には上巻を読み切ることができたので、今回は下巻の感想を書いていきます。

aki-m.hatenadiary.com

aki-m.hatenadiary.com

本書で印象的だったこと

欠陥検出率のデータ

単体テストや機能テストを実施するのみでは、それぞれ30%程度しか欠陥を検出できないということに驚きました。
その一方で、モブプログラミングや複数人が集まるコードレビューではそれぞれ60%程度の欠陥を検出することができており、自分のイメージとは逆の結果(レビューが30%でテストが60%)だったので驚きました。
ただし、上記で挙げたような欠陥検出のための方法は、他の方法と組み合わせすることで高い効果を発揮するということなので、一概に単体テストや機能テストの効果が低いという訳ではない点には注意が必要です。
テストや品質保証の仕方は、画一化できるようなものではなく、毎回品質保証のための戦略を立てて実施する重要性を改めて実感しました。

エラーは一部のクラスに集中する

これは自身の経験と一致していて、「根拠となるデータがあったのか!」という感じでした。
1975年のデータということで、信憑性は大分怪しいですが、1つのルーチンを修正することで85%のエラー(バグ)が治るというのは、衝撃でした。

エラーの三大原因

これも1988年のデータということで信憑性が怪しいですが、アプリケーション分野の知識不足・要求の理解不足(要求変動や矛盾)・コミュニケーション不全(協力体制の不備やコミュニケーションミス)が三大原因ということでした。
技術的なミス(配列の操作ミス、デッドロックTypo...)が殆どの原因を占めているのだろうと思っていたので、驚きました。

ソフトウェアプロジェクトの工数に影響する要因

工数を増やす要因は、

  • 開発現場の分離
  • ドキュメントの充実度
  • 担当者の入れ替わりの頻度
  • プログラマの能力
  • 要求アナリストの能力
  • 要求される信頼性
  • チームの結束力
  • チームの経験(アプリケーション分野に対する経験&テクノロジーに対する経験)
  • ソフトウェアツール

等々多数ありますが、工数を増やす一番の要因は、ダントツで製品の複雑さとなっていたのが驚きでした。
勿論、製品の複雑さが工数を増やす影響になっているのは間違いないと思っていましたが、要求アナリストの能力(+42%の工数増)やプログラマの能力(+34%の工数増)を遥かにしのぐ、+74%の工数増という値に驚かされました。
また、数値化できないが、工数に影響を与える故に必ず考慮しないといけない指標として、チームの意欲や顧客との関係性, 要求策定へプログラマ&ユーザがどれ位貢献するか...が挙げられていました。
いずれも疎かにされやすい指標ではありますが、どちらの指標についても、現場で疎かにされた結果大変な状況になった経験があるので、身に沁みました。

資質は才能とはほとんど関係がない

本書の大部分はソフトウェア開発に関する実践的&詳細な解説だったので、突然出てきたこの言葉はより一層刺さりました。
エンジニアとしての道を歩み出したのは遅めな実感がありますが、今ある差は努力でどうにでもなるということで、これからも勉強&アウトプットをし続けていきたいと思います。

全体を通した感想

システム開発のすべてについて、詳細な解説と多数のリファレンスが記載されていました。
本書&リファレンスの内容を完璧に理解することができれば、プログラミングをコンプリートした、と言っても良いのではないかとすら感じました。
ソースコードが古いのと、調査データが古くて信憑性が若干怪しい点だけは残念ですが、そのデメリットを補うだけの価値がある本だと感じました。
読み切ったはいいものの、正直7割~8割くらいしか理解できた自信はないので、これからも勉強を続けて、また知識がついてから読んでみて、新しい発見が見つかるのを楽しみにしたいです。