どんな内容なのか
アジャイル開発やオブジェクト指向で有名な著者（ボブおじさん）が自らの失敗を赤裸々に語りつつ、ソフトウェア開発者が本物のプロへと成長する方法を指南する啓発書です。
読み始めた背景
なぜこの本を読み始めたかというと、"ひまじんプログラマーの週末エンジニアリングレッスン"というポッドキャストでボブおじさんの話をしていて気になったからです。（本当はClean Codeを買おうとしていたのですが、間違えてClean Coderを買ってしまいました。笑 結局ためになることばかりだったので買ってよかったです！）
各章のまとめ
第1章 プロ意識
プロとは自分の仕事に責任を持つことで、ミスをした場面では自分で後始末をするものである。業務に関しては、バグの数は限りなく0に近づけることに責任があり、QAがバグを見つけないことが理想である。
プロは慌ただしく変化する業界で取り残されないために継続的に学習をする。本・記事・ブログ・ツイートを読んだりカンファレンスに行ったり読書会や勉強会に顔を出したり、新しい言語を学んだり、常に知識をアップデートするのである。
第2章 「ノー」という
もし難易度の高い開発の依頼が来たら、「やってみます」ではなく「ノー」と言わなければいけない。また、その際は技術的に難しいことや時間がかかるという事実を説明しなければいけない。そこからビジネスサイドと開発サイドで合意できる解決策を導き出すことがプロの振る舞いである。
「試しにやってみる」とは言ってはいけない。なぜなら仕事はやるか、やらないかだからだ。「試しにやってみる」というときは失敗した時の新しいプランがある時である。プランがないときはやるか断るか選択しなければならない。
第3章 「イエス」という
約束をするときには自分で約束の内容と期日を明言することが重要である。「する必要がある・しなければいけない」「〜するといいんだけど・〜したい」「やりましょう（「私が・・・」ではない）」といった言葉を使って個人的な責任を逃れようとするのではなく、自分でやり遂げることを約束するのだ。約束の言葉を言うのは怖いかもしれないが、結果的に周りは自分の言葉に忠実に行動する真面目な開発者だと認識してくれる。
プロは頼まれたこと全てに「イエス」という必要はない。しかし、「イエス」と言えるような創造的な方法を懸命に探さなければいけない。
第4章 コーディング
疲れている時にコードを書いてはいけない。献身やプロ意識というのは、労働時間ではなく規律を守っているかどうかである。睡眠・健康・生活様式を調整して、1日に8時間は満足のいく時間を作らなければならない。
書きたいのに書けないことがあるかもしれない。そんなときは他の仕事をする。メールを読んだり、ツイートを読んだり、本やスケジュールや文書を眺めたり、会議を開いたり。一番効果的なのは「ペアのパートナーを見つける」こと。ペアでコーディングをすることで心理的な変化が起きて気持ちいいほどうまくいくのだ。
プログラマはお互いに助け合えるようにしておかなければいけない。一人の時間もとりつつチームメンバーが話しかけやすいような環境を作っておく。手伝いを申し出てもらったらお礼を言い、喜んで手伝いを受け入れよう。協力を働きかける規律が効果的なプログラミングには欠かせない。
第5章 テスト開発駆動
TDDの３原則は以下の通り。
- 失敗するユニットテストを書くまでプロダクションコードを書いてはいけない。
- テストを失敗させる目的以外でユニットテストを書いてはいけない。なお、コンパイルできないものは失敗に含まれる。
- 失敗しているユニットテストが成功するまで他のプロダクションコードを書いてはいけない。
このサイクルをぐるぐると回していき、テストがプロダクションコードと結びついていくようにコードを書いていく。
TDDのメリットは、
- 確実性：一部に変更を加えるときは最初にユニットテストを実行する。テストが成功すれば他の部分を壊していないことがある程度は確信できる。
- 欠陥混入率：TDDを実施することでケナン混入率を非常に低い状態に保つことができる。
- ドキュメント：ユニットテストはドキュメントである。低レベルのシステム設計を説明したものだ。明確で正確で理解できる伝語で書かれていて、おまけに実行もできる。
第6章 練習
武術もプログラミングも、スピードは練習の成果である。その練習はどちらも似ている。問題と解決策からなる題目を選び、完全に習得するまで何度も実行するのだ。
- 型：ホットキーや操作のイディオムの学習に適している。TDDやCIなどの規律の学習にも優れた方法である。そして、最も重要なのは、よくある問題と解決策の組み合わせを潜在意識に植え付けることで、現実のプログラミングの問題解決方法がわかるようになる。
- 技：二人組になって技の練習を繰り返し行う。一人がユニットテストをかき、もう一人がテストを成功させる。役割を交代しながら何度も何度も繰り返すのだ。
- 乱取り：3人以上で技の練習を行なっていく。ここでは、他の人が問題を解く様子がよくわかり、自分のやり方を改善させてスキルを向上させることができる。
全てのプロは、何らかの形で練習をしている。また、スキルを磨くのは自分の責任であり、雇用主の責任ではない。そのため、練習というのは給料が支払われない時にやるものである。
第7章 受け入れテスト
「受け入れテスト」という言葉は、さまざまな意味で用いられている。リリース前に顧客が実行するテストだという人もいれば、QAテストのことだと思っている人もいる。本章で使う受け入れテストとは、要求の完了を定義するために、ステークホルダーとプログラマが協力して書くテストのことである。
受け入れテストは常に自動化しなければいけない。理由は単純で、コストがかかるからだ。自動化ツールにはFitNesseやCucumber,Seleniumなどオープンソースや商用のものなどたくさんあるので、それらを使うべきである。
受け入れテストはユニットテストではない。ユニットテストは、プログラマがプログラマのために書くものだ。受け入れテストは、ビジネスがビジネスのために書くものだ。ビジネスの観点からシステムの動作を定式化した要求文書である。受け入れテストもユニットテストも、第一にドキュメントであり、第二にテストである。第一の目的は、システムの設計・構造・振る舞いを定式的に文書化すること。仕様として定めた設計・構造・振る舞いを自動的に検証できるというのも便利だが、仕様の文書化が本来の目的である。
第8章 テスト戦略
ソフトウェアをテストするQAグループが部門として分かれていたとしても、開発グループは「QAは何も見つけてはいけない」を目標としなければいけない。しかし、これは開発とQAが敵対するという意味ではない。開発とQAは協力してシステムの品質を向上させるべきである。
- ユニットテスト：ユニットテストの目的は、システムを低レベルから仕様化することである。開発者はプロダクションコードを書く前に、今から何を作るかを決めるためのユニットテストを書く。ユニットテストを継続的インテグレーションで実行すれば、プログラマの意図が維持されていることを確認できる。
- コンポーネントテスト：これは、受け入れテストの一種だ。入力データをコンポーネントに渡し、出力データを集め、出力データと入力データがあっているかをテストする。
- インテグレーションテスト：これは、コンポーネントの数が多い大規模システムに使う。コンポーネント間のやり取りがうまくいっているかをテストするのだ。インテグレーションテストは実行時間が長いので、継続的インテグレーションに含めず、必要だと思う間隔で、定期的に実行する。
- システムテスト：統合したシステム全体をテストする自動テストのことで、究極的なインテグレーションテストである。システムテストはシステム約10%を網羅する。これは、システムの振る舞いではなく、構造を確認するものだからである。
- 手動探索テスト：実際にキーボードを操作して、画面を確認しながら行うテストである。できるだけ多くの「異常」を創造的にみつけるものである。
第9章 時間管理
8時間を効率的・効果的に使うためには時間管理が重要だ。
会議に対する考え方を変えることが、仕事の効率を上げることを助けるかもしれない。招待された全ての会議に出席する必要はないのだ。自分の時間を管理できるのは自分だけだ。自分のプロジェクトを優先する責任があるのだから、自分の時間を消費するだけの会議は参加しなくてもいい。
プログラミングとは長時間の集中力と意識を必要とする知的行為である。プロの開発者は、集中力の持続性も意識しながら時間を管理している。集中力があるときはコードを書き、集中力がないときは生産性の低い別の何かをする。
第10章 見積もり
見積もりに関しては、人によって捉え方が違うことで少々問題になる。ビジネス側は見積もりをコミットメントだと思っていて、開発者は、見積もりを予測だと思っている。この違いが大きい。実際、見積もりは予測である。
プロのソフトウェア開発者は、ビジネスが計画を立てるのに使えるような実用的な見積もりを提供する方法を知っている。守れないような約束はしない。果たせないようなコミットメントはしない。プロの開発者は、マネジメントに渡す見積もりを他のチームメンバーと一緒に見積もる。
第11章 プレッシャー
プレッシャーをうまく扱うコツは、できるだけプレッシャーから逃れることだ。それができなければうまく乗り越えるのだ。プレッシャーから逃れるには、コミットメントを管理して、規律を守り、クリーンに保とう。プレッシャーを乗り越えるには、落ち着いて、コミュニケーションをとって、規律を守って、助けを呼ぼう。
第12章 協力
プログラミングとは誰かと一緒に働くことだ。プログラマは一人で黙々とコーディングに没頭することが好きで開発者になった人が多いだろう。しかし、雇用主や他のプログラマと協力しなければビジネスを進めることはできない。
第13章 チームとプロジェクト
チームづくりには時間がかかる。チームメンバの関係づくりから始めて、お互いに協力の仕方を学ぶのだ。お互いの変な癖・長所・短所を学び合い、最終的にチームはゲル状になる。ゲル状のチームはお互いを助け合い、柔軟に働きあうことができる。プロジェクトごとにチームを形成・解散するのはコストがかかる。よって、一つのチームがプロジェクトを移動したり、同時に複数のプロジェクトを担当するのがいいだろう。
第14章 指導・徒弟制度・職人気質
コンピュータプログラミングの理論は学校で教えることができる。しかし、職人になるための規律・訓練・技能は、学校では教えてくれないし、教えることもできない。大学ではなく、実務の中で開発のプロたちが徒弟制度・インターンシップ・長期的な指導といったプログラムを導入しなければいけない。
さいごに
実際に起こったことをもとに教訓が書かれていたので、とても読みやすく、理解しやすかったです。また、プロの開発者としてどういった思考で日々業務や自己研鑽を行なっていくかというのが明確に書かれていたので、この指針に則りながら開発者としてステップアップしたいと思いました。
参考文献