オレたちのUncle Bobが帰ってきた！
ITエンジニアが読むべき名著にオールタイムで名前が上がるCleanシリーズ。作者はアジャイルマニフェストのその場にいた一人でもあるロバート・C・マーチン御大、通称Uncle Bob。→Wikipedia: Robert C. Martin, プログラマが知るべき97のこと
『Clean Agile』に続く本書は、クラフトマンシップをもったプロのエンジニアであろうという在り方をメインに述べ、過去の一連の本で述べられてきた主張も含めた集大成的な本になっています。
おおお...あのシリーズに続きが出た...ということで震えながら読んだので以下読書記録です。
- オレたちのUncle Bobが帰ってきた！
- 第I部 規律
- 第1章 クラフトマンシップ
- 第2章 テスト駆動開発
- 第3章 テスト駆動開発応用
- 第4章 テスト設計
- 第5章 リファクタリング
- 第6章 シンプルな設計
- 第7章 協力的プログラミング
- 第8章 受け入れテスト
- 第II部 基準
- 第9章 生産性
- 第10章 品質
- 第11章 勇気
- 第III部 倫理
- 第12章 有害
- 第13章 誠実
- 第14章 チームワーク
- まとめ：クラフトマンシップかくあるべき＋ボブおじさん本の集大成
第I部 規律
第1章 クラフトマンシップ
より良く働き、生産性を高め、自分が書いたものに誇りを持つクラフトマンたる気持ちを持ったエンジニアであろう...ということで根本の章。原題では規律：Disciplines、基準：Standards、倫理：Ethics なんですね。日本だと古くなった感もあるXP、TDD,リファクタ、シンプルな設計、協力的プログラミング、受け入れテストの話が出てきます。
第2章 テスト駆動開発
素数の生成やボーリングのスコア計算、バブルソートにクイックソートを題材にし、狭義のほうのテスト駆動開発(TDD)のやり方を実際のコード片から観ていきます。
最初は失敗するテストコードを書いてから対象の関数を徐々に実装していくやり方、僕も実務ではやっていないのですが本書は段階的に説明しているのでイメージが湧くかもしれません。UMLを使った厳密なクラス設計に頭を捻ってからコードを書き始めるより、こちらのテスト駆動でコードを書いていくやり方のほうが速く進められるシーンも出てきます。
UMLも2000年代のJavaとオブジェクト指向全盛期はもてはやされたものですが、最近聞かなくなりましたね...
第3章 テスト駆動開発応用
後半ではテストダブル、ダミー、スタブ、スパイ、モック、フェイクの本書での定義の差が分かりやすい。このへん混合しやすいです。
第4章 テスト設計
データベース自体はテストしないでクエリをテストせよ、GUIはテストしないか小さくやれ...と設計の章。
TDDを解説したいろんな本や記事でも昔はテストクラス：テスト対象クラスを1：1と定義したものもあり、こちらベースで考えてしまいがちですが、これをファクタして分割してきれいに仕上げ、テストクラス：テスト対象クラス(というか処理)が1：Nでも等価のことができることを例を上げながら解説しています。確かに今どきですとクラスでなくひとつのAPI単位とかで作ることもあるかなあと思ったり。
名著『リファクタリング』にも乗っているレンタルビデオストアの処理例がお題になっているのも面白いです。
最後の変換の優先順位説で、経験から導かれた順位が書いてあります。これはやはり、失敗すること前提のメソッド実装でテストコードを繰り返しながら対象メソッドを徐々に実装していくケース限定のものでしょうか。
というように本書はソフトウェアエンジニアのあり方全般を論じていますが、前半はかなりみっちりとTDDの話が続きます。TDDやってなくてスミマセン...と思いながら読みました。なおコードはJavaですが、他の言語がメインの方もそんなには詰まらず読めるかと思います。
第5章 リファクタリング
章の挿絵が同じくレジェンド級の人、マーチン・ファウラー大先生になっておられます！
ソフトウェアのふるまいを保ったまま、構造を改善していく変更で、変更のたびにテストコードを実行させていく...とCleanシリーズなりに改めて言いかえて、本書では簡単な例に留めています。詳細は書籍『リファクアリング』を参照、ということでしょうか。
第6章 シンプルな設計
シンプリシティを追求する章。高レベルの方針を低レベルの詳細から分離する抽象化が最も少ないのが良い、として、マシン性能が低かった昔は反対のことをやっていた...という話が面白い。技術的躍進の後にYAGNIが生まれたのですね。歴史から学べることはやはりあります。
ケント・ベックさんの提唱する「カバレッジ」「表現力」「単数化」「縮小化」の４原則を守りさえすれば他の原則も満たされるかというと分からないとも書いてあり、やはりこのへんの設計の話は絶対のルールはないのだなあと思います。
第7章 協力的プログラミング
エンジニアは複数で協力し合ってやっていくものだ...ということで簡単にモブプログラミングの話。ジュニアエンジニアはジュニア同士でやりたがる傾向があるというのが興味深い。必要以上にやっていれば注意するようあります。新人同士で馴れ合っちゃったりするようなものでしょうか。
なおモブプロはシニア同士でやってもよいとのことですが「部屋に武器がないことを確認しておこう」というジョークが隠されています。そんな怖いシニアエンジニアと同じチームはイヤ！(笑)
第8章 受け入れテスト
自動化できる言語の話としてFitNesseの話。
第II部 基準
ボブおじさんがあなたの新しいCTOになったと仮定して、プロフェッショナルとしてキミに期待しているレベルはこれなんだ...! と熱く語りかけてくる部。TDDの話以降は実際のコード例はあまり出てこず、読み物として楽しめます。
第9章 生産性
あなたのCTOとして期待することは...SHITなブツを出荷しない、リリース後の変更要求に比例したコストで対応できる適応力を持つ、自動化して継続リリースできる状態を保って準備万端にせよ、そしてコードをクリーンに保って安定した生産性を保つ、というお話。
Cleanシリーズなのでこの「クリーンに」という表現はあちこち出てきます。『Clean Code』も名著なので未読の方はいつか触れることをオススメしたいです！
第10章 品質
クラフトマンの仕事として品質を高め、維持していく話。
- 継続的改善：コードはチェックアウトしたらチェックインするときはよりクリーンに。
- 恐れを知らない能力：システムが複雑になっても変更を恐れず、テストやリファクタを武器に立ち向かってほしい。
- エクストリームな品質：振る舞いと構造に欠陥のないソフトウェアをデリバリーする。ないし目指す。
- QAを軽視しない：QAの仕事を理解し軽視しない。
- QAは何も発見しない：プロセスの最後でなく最初に。プログラマーがバグを発見してQAは何も発見しないのが望ましい。
- テストの自動化：人間の判断が必要なGUIテストなどは手動、残りをできる限り自動化する。
- 自動テストとユーザーインターフェース：関数はUI経由でなくAPIからテスト。逆にUIのテストの際は奥をスタブに。
自動テストの分野もいろいろ研究されたりツールが出たりしましたが、結局GUIのテストって決定打はないなあといつも思っていました。本書でもGUIは人力でとなっていますね。
第11章 勇気
- お互いをカバーする：互いに助け合いチームの目標に向かって進捗を。
- 正直な見積もり：アジャイルのストーリーポイントのような相対見積もりを活用、不確実性を示す正直な見積もりを。
- ノーと言う：スケジュール上できないことはノーとはっきり断る。
- 継続的挑戦的学習：ソフトウェア業界はダイナミックに変わっていく。毎年1つ新しい言語を学ぶのもよい。時間を確保、活用する。
- メンタリング：新人プログラマーの教育も重要な仕事。誰かの学習を支援する。
嫌われる勇気ならぬ「ノー」と言う勇気...! このへんもCleanシリーズの『Clean Coder』で見たような話題が再度語られています。この本は僕は物理本で持っているのですがこちらもオススメです。
毎年1つ新しい言語を学ぶぐらいの気概を持つとよい話は『達人プログラマー』でお馴染みですね。
第III部 倫理
最初のプログラマーとして、アラン・チューリング氏から始まって歴史の話。1世紀立経たないコンピュータの性能が指数関数的に高まり、プログラマー人口も爆発的に増え、認知度や役割も変わってきたのがよく分かります。映画で『ウォー・ゲーム』や『ショート・サーキット』、1作めで完全に悪いイメージのギークなプログラマーが悪役で出てくる『ジュラシック・パーク』、そして『マトリックス』が出てくるのが懐かしい〜！ Cleanシリーズはこういう歴史的背景も語られているのが楽しい。
そしてソフトウェアを通し「我々こそが世界を支配している」のであり、惨事を避け良きプログラマーとして振る舞わなければならない...ということでアツい10条からなる「プログラマーの誓い」がここで提案されます。
第12章 有害
約束1: 第一に、害を与えてはならない：社会、機能、構造に害を与えてはならない。何よりもテストを。ソフトウェアは急いでもよいものは作れない。
約束2 コードは常に私の最高傑作である：動くコードから正しいコードへ。良い構造を目指す。プロとして状況の中でベストを目指す。
約束3 コードが正常に動作する証拠をリリースごとに用意：ダイクストラのアルゴリズム証明と構造化プログラミング、TDDの話へ。
このへんは人類のソフトウェア業界史の中で起こった事件や惨事、発見をなどを交えて進んでいきます。他の書籍でも時々出てきますが、過去にもプログラムのコードが原因で人工衛星やロケットが落ちたり人が死んだり金の大損害が出たりしたこともあるんですよね。姿勢をシュッと正さねば...
第13章 誠実
約束4：誰かの進捗を妨げないように小さく何度もリリース
本章では1960年代から始まってソースコード管理の歴史としてパンチカードの貴重な写真、掲示板で特定テープをチームの誰がいじっているかを示した写真などを交えて解説しています！ CVSやSubversionが出てきて最後はGitに繋がるのですが、このへん最近エンジニアになった人には歴史的に貴重なのではないでしょうか。
- 短いサイクル：短くなるにつれマージのコスト発生。新しい戦略へ。
- 継続的インテグレーション：コミットする間隔を狭めればマージの手間もかからず、Subversion以降のツールなら可能。こうしてCIが生まれる。根底にあるのは昔から、他の人の進捗を妨げないようにすること。
- ブランチとトグル：ボブおじさんも昔は、むやみなブランチを警戒するブランチ警察の人だった。Gitが登場してから変わった。
- 継続的デプロイメント：手順は自動化し、サイクルは徐々に短縮して、安全なデプロイがいつでもできるように。
- 継続的ビルド：Jenkins、Buildbit、Travisなどを活用。ビルドが失敗したらアラーム、決して許さないように。
約束5：執拗に自分の作品を改善する。「ボーイスカウト・ルール」
- テストカバレッジ：値をごまかすことなく、コードを改良するためのツールとして使う。実際には100%には届かなくても意味のある100%を目指す。
- ミューテーションテスト：コードに意味的な変更を加えてテストするもの。テストは失敗するはずである。時間がかかるがやるとよい。
- 意味的な安全性；カバレッジとミューテーションで求められる。
- クリーニング：改良を目的としたリファクタリング。コードを柔軟に。
- 作品：コード以外のドキュメントなども全て、継続的な改善すべき「作品」である。
約束6：自分や誰かの生産性を高めるためにできる限りのことをする
- 高い生産性＝速く進む方法＝うまく進むこと。
- 効率化：コーディングの時間がそれほど短縮されない。コーディング以外のプロセスを効率化させる。ビルドが遅くなる原因を突き止める。テストもスピードアップ。ログインやUIなど余計な処理を挟まずテスト対象の処理だけをテスト。TDDや受け入れテスト、カバレッジなどをしていればデバッグ時間も短縮される。デプロイもスクリプトで自動化する。
- 集中力：ミーティングが退屈だったら挨拶して途中退出する。不要なミーティングを遠ざける。
- 音楽は集中力が高まるように感じるだけで低下していたのでボブさんはやめた。人と喧嘩したりしたときは感情に合わせて行動する。適切な行動をしたと納得できれば気分が変わる。フロー状態も、興奮状態で書いたコードはひどいことが分かった。ボブさんは今はフロー状態に入らないようにしている。
- 時間管理：ポモドーロ・テクニックがよい。人から割り込みが入ったら、トマトの時間の25分後にまた会うようにするとよい。
僕はリモートワーク中は音楽は聴きながら作業するのがデフォルトなので、音楽をやめてみたボブおじさんの意見はへえ〜と思いました。昔のイケてないコードを見ていたらその時聴いていた歌詞がコードコメントに書いてあってダメなコードになっていた..という逸話は、いやそうはならんやろ！と声を上げて笑ってしまいました。かのUncle Bob御大でもそんなことあるんですね。うーんよっぽどノリノリの激しいロックとか聴いていたんでしょうか。
フロー状態否定もへえ〜と思いました。他人と一緒にペアプログラミングしているとフロー状態には入らないそうで、確かにそうですね。
第14章 チームワーク
約束7：他の人が自分をカバーできるように、自分が他の人をカバーできるように務める
人と共に働く話の章の章。
- オープンオフィスとバーチャルオフィス：本書もボブおじさんがコロナの中で執筆。ペアプロやモブプログラミングのときはビデオをオンにして顔を見えるように。できるだけ同じ時間帯で作業。物理的に集まる機会を作ったほうがよい。
約束8：規模と精度の両方を正直に見積もり、合理的な確実性がないときは約束しない
見積もりの話。
- 納期から逆算して作ったほとんどの見積もりは嘘である。
- 実作業してみると大幅に予想と違うことはしょっちゅう。見積もりは日付でなく確率分布である。最良ケース、最悪ケース、最有力ケースで見積もる方法。確率分布でやる方法。マネージャーになんと言われても確証がなければイエスと言ってはいけない。ノーと答えるべき時を知っている能力も重要。
約束9：仲間のプログラマーの倫理、基準、規律、スキルを尊重。その他の属性や特性は尊重の要因にはしない
- 差別はしない。人を尊重する。尊重されるにはスキル、規律、基準、倫理が必要。
約束10：技術の学習と向上を怠らない
- プログラマーとしての学習をやめない。優れたプログラマーは10個以上の言語を知っている。毎年新しい言語を学ぶのもよい。学ぶべき領域は無限で変化が続くが、それについていく。
- 本やブログ、動画、カンファレンス、ユーザーグループ、古くても偉大な書籍を読む。自分のキャリアなので自分で責任を持つ。学習の計画も立てる。週に35−40時間働くなら10−20時間は学習に充てる。
平日8時間働いて週40時間労働、学習に週10時間(月40時間)は資格試験対策期間ならいけるけど週20時間(月80時間？)はけっこうハードルが高いかな？と思いました。本書に感化された独身で若手層のジュニアエンジニアなら行けるのでしょうか。
とはいえ学び続けることが重要というのはどこでも言われているので、啓蒙の意味での本書の主張はそのとおりです。
まとめ：クラフトマンシップかくあるべき＋ボブおじさん本の集大成
読んだあとに熱量をもらって意識が高くなるいつものCleanシリーズだった...と噛み締めながら読了しました。
こちらもお馴染み、翻訳にあたった角征典さんのあとがきが面白いのですが、ソフトウェアクラフトマンシップの歴史はあの『達人プログラマー』(厳密にはもっと前の本)から始まったそうです。
そしてアジャイルが注目されたけど形が変わってゆき、ソフトウェアクラフトマンシップの宣言もされたがこちらもうまく行ってないようで、それだけエンジニアの人数がアメリカでも爆発的に増えているのですね。
本書の中でもそのへんを危惧し、エンジニアはどんどん増えるけど彼らを指導できる層の人数が足りない、過去の歴史や経緯、教訓、規律、基準、倫理をもっと若手に伝えていかなければならない...という話がいくつか出てきます。
過去のボブおじさんの本をほぼ全部読んでいる自分としてはこのあとがきにある「またこの話か」「これ見たことある」も結構出てきました。それでも新しい話も出てきますし、Uncle Bob本総集編としても楽しめます。Cleanシリーズはズバッと言い切る主張の激しさが楽しいですが、本書はこれまでの本に比べるとマイルドな気がしました。(いや、単に読み慣れてきただけかも...w)
なお本書を記念したイベントでの情報によるとボブおじさんは1952年生まれでもう70歳、出す本は本書が最後になる(らしい)とのことです。寂しい...でもさすがにお年でしょうか。69歳とか70歳でこれだけ熱量のある問いかけをエンジニア界に投げかけてくれるというのも凄い。
あとがきにある「見習い」よりは「十分に偉そう」な方に僕も一応入れるのかなあ...と思いつつ、ボブおぢさんの職人魂のアツいパワーを貰える本でした。クラフトマンシップの誇りを持ったエンジニアとして姿勢を正し、後続の手本とならねば...と改めて身の引き締まる思いです。(シュッ)
おまけ
この記事の中でもいくつか言及しましたが、ボブおじさんの一連の書籍である「Cleanシリーズ」。
『アジャイルソフトウェア開発の奥義 第2版』は原著2002年で第2版の翻訳が2008年、電子化もされてないし古めなので僕も未読なんですよね〜。
続く5冊がCleanシリーズ。オールタイムで必ず名前が上がる名著なのでITエンジニアならどこかで読むことをお勧めします！
