Clean Craftsmanshipを読んだ
仕事から家に帰ったとき、鏡に映った自分を見て「今日はいい仕事をした」と言うだろうか？それとも、すぐにシャワーを浴びるだろうか？
あまりにも多くの人たちが、一日の終わりに心残りを感じている。あまりにも多くの人たちが、標準以下の仕事をしていると感じている。あまりにも多くの人たちが、品質を犠牲にして速度が求められていると感じている。あまりにも多くの人たちが、生産性と品質は反比例すると考えている。
本書では、そうした考え方を打ち破る。本書はより良く働くための本だ。良い仕事をするための本だ。 仕事を速くして、生産性を高め、毎日自分が書いたものに誇りが持てるように、すべてのプログラマーが知るべき規律とプラクティスについて書いた本だ。 （p. 18「はじめに」）
2度目の『Clean Craftsmanship』を読み終えた。1度目は読書会に参加する形で、今回はチームの読書会を主導する形で読んだ。自身の普段の仕事に対するものの見方を後押ししてくれた。端的に、勇気を与えられた。 本書を読む前は、漠然とした「私は正しいことをやっているのか」という迷いが多くあったが、迷いが減り、目前の仕事に集中できるようになり、自らの仕事に自信が持てるようになった。この効用は大きい。
他のCleanシリーズ、『Clean Architecture』や『Clean Code』に比べて知名度が低いように思うが、本書を読む人が増えてくれると嬉しい。
サブタイトルに「規律、基準、倫理」とある通り、本書のよいところは、社会に生きる職業人のプログラマとして持つべき考えについて述べている点にある。類似書に『達人プログラマー』や『チーム・ギーク』などがあるが、プログラマーの社会的・歴史的位置づけについて書かれた本は他にはないのではないだろうか。 倫理や社会と聞くと警戒する人もいるかもしれないが、押し付けがましい説教を延々聞かされるのではないので安心してほしい。
訳者あとがきにもあるように、「過去の著作から大事なことが抜粋されてまとめられているため、大変オトクなパッケージにもなっている」。他のCleanシリーズや類書で見覚えのある話が多々現れる。
- テスト駆動開発
- 基礎、なぜTDDなのか
- ドキュメンテーションや設計との関係性
- テストの効果
- テストの壊れやすさ
- 不確定性問題
- データベースやGUIのテスト
- 高速なテスト
- アーキテクチャの境界線
- リファクタリング
- シンプルな設計
- YAGNI
- 偶然の重複
- 協力的プログラミング
- 継続的ビルド
- などなど
ソフトウェア・テストの技法や考え方に注目して言えば、『単体テストの考え方／使い方』が理解を助けてくれると思う。重複する部分も大いにあるが、この2冊を読むことで習熟度がぐんと上がると思う。プラクティスや、物事をうまくやるための基本的な考えかたに注目して言えば、『エクストリーム・プログラミング』を併読するのがよいだろうと思う。
大変オトクなパッケージであると同時に、人類史の参照もありがたい。
- 航空機開発と事故の歴史
- 手洗い法（センメルヴェイス・イグナーツ）
- 複式簿記（ガイウス・プリニウス・セクンドゥス）
- ナイト・キャピタル・グループの事例
- HealthCare.govの事例
- など
当然、コンピューターやプログラマーに関する歴史にも触れている。
第2章から第5章（p.41〜p.207）はテスト駆動開発とリファクタリングの実践が主である。ミーティングツールの音声をオンにして、チームメンバーとワイワイそれぞれ好きな言語で実装するのは楽しいし、テスト駆動開発の威力が体感できるいいワークショップになると思う。ただ、それなりに時間がかかる。ちなみに、私は1度目はDeno、2度目はJavaで実装した。
Cleanシリーズを読んだことのある人にはお分かりかもしれないが、相変わらず語気は若干強めで、読了後の感想戦でもちらほらとそういった感想があった。筆者のスタイルに調子をアジャストして読むのはよくある読書スキルであるし、「はじめに」で著者もこう書いている。
本書を読むと、これこそが「クラフトマンに到達するたったひとつの道」だと感じるかもしれない。だが、私にとってはそうであっても、あなたにとっては必ずしもそうではないかもしれない。本書はあくまでも私の道を示したものだ。あなたには、もちろん、あなた自身の道を選択する必要がある。
とはいえ、TDDに対する姿勢については、人によっては解説が必要かもしれない。例えば、テストのカバレッジについて第6章で以下のように記している。
カバレッジの数値はいくつにすべきだろうか？80％だろうか？それとも90％？多くのチームがそのような数値を満足気に報告している。だが、さきほどの60年前の論文の答えは違う。彼らの答えは「100％」である。
TDDには諸派あり、必ずしもテストファーストのアプローチを取らなかったり、カバレッジをどの程度重視するかなど、グラデーションがある。私は、テストファーストのアプローチを取ることが少ないし、カバレッジをさほど重視しない。コストパフォーマンスのバランス重視であるといえる。そのために、100%を漸近的な目標として掲げることには懐疑的だ。このように書いてあること全てを信じる必要はないのである。
（…が、ミューテーション・テストの効果を再発見したり、「1対1の対応関係」を「対応関係の解消」する様子を見ていると、100％を目指すのが正解のようにも思えて来るし、単体テストをよりテストサイズの大きな領域に移行することを考えると、逆に不正解のようにも思えてくる。）
TDDの諸流派の話については、fukabori.fmの114回でt-wadaさんが詳しく述べられている。
