Clean Craftsmanship 規律、基準、倫理 - 読書メモ
「Clean Craftsmanship 規律、基準、倫理」を読んだ。 Robert C.Martin (著), 角 征典 (翻訳)で、原著は「Clean Craftsmanship: Disciplines, Standards, and Ethics」。
Cleanシリーズなので読んでおいて損はないと思い、読んだ。
まず一番に感じたのはプロ意識をしっかり持つべきだと感じた。 ソフトウェアは、とてつもなく生活や社会に浸透しておりなくてはならない。ソフトウェアが動かなくなったり、意図しない挙動(バグ)によって人の命や生活を脅かされることまである。
書籍にも書かれていたが、医者が手術前に手を洗う際の規律の紹介がある。この規律を守ることにより多くの命を助けることができるようになった。ソフトウェア開発者も同じような立ち位置にあるため規律が必要だと筆者が書いている。
これはとても心に刺さった。他のものと正確に比較はできないとは思うが、建築や医療現場にはいろいろな規律がありそれによって安心・安全が守られている。ソフトウェアは物理的に存在しないため実態が見えず、そのようなルールが守られにくい・軽視される傾向にあるのだと思われる。
ソフトウェア開発も、わかりやすくよみやすい、変えやすく壊れにくく作るための規律を守って作っていくべきだと感じた。まさにクラフトマンシップ。プロ意識みたいなのをしっかり持ってコードを書くべきだと。
ソフトウェアクラフトマンシップの規律
基本的な規律は5つ
- テスト駆動開発
- リファクタリング
- シンプルな設計
- 協力的プログラミング
- 受け入れテスト
まずテスト駆動開発(TDD)がなければ、他の規律は無力になる。リファクタリングは、TDDがなくても不可能ではないが困難になる。 そのためTDDが一番大切な規律であるとのこと。
その他印象に残ったポイント
偶然の重複
DRY原則によって重複を排除して共通化を行ったりする。しかし、その重複が本質的に同じであるかどうかは、コードの意図に依存する。
コードの意図をしっかり表現できていれば、本質的に重複しているのか、偶然重複しているのかを区別しやすくなる。偶然の重複はただ似ているだけであって、排除すべきではない。
これに立ち向かうには、ドメインをしっかり理解したり、ユビキタス言語をしっかり話し合い決める必要があるのだと思う。TDDしながら語彙を確かめるのも大事だと思う。
私の実体験、仕事でとある用語を仮で決めていたが納得いかない表現であったため、数名で決めるミーティングを開いた。 いろいろな言葉が出てくる中、100点と思えるものがなかなか出てこない。数時間くらいはなしており、妥協案で終わりにしようとさえ思っていた。
実際のテーブル定義、シグニチャなどを当てはめて書いてみたり、現在の要件・将来要件など照らし合わせながら話していくと、ある人が出した言葉が120点くらいにぴったりくる言葉が見つかったことがある。その場にいた人全員賛成になり決まった。個人的には感動的な出来事だった。
この作業がなければ、コードの意図をしっかり表現できずわかりにくいコードになっていたのではと思う。
ケント・ベックがXPで使った言葉「容赦ないリファクタリング」の紹介がp205にあった。容赦してはいけないのかも知れない。
QAの仕事
p243
QAの仕事は、システムの振る舞いをテストで指定すること。
QAプロセスが最後にいるなら何も発見しない
QAが、動作確認というcheckingだけのテストをやっているだけなら品質は上がらない、ということに気が付けた。
品質を担保するためには、どのようなテストを行うべきかを検討してもらい、それをプログラマに義務づける必要があるためQAプロセスは最初のほうにあるべき。
p243
全てのバグを発見するのはプログラマの仕事
そしてこれは、プログラマとしての規律なのだと思う。
気になった部分のメモ
p40
受け入れテストとは、ソフトウェア開発チームをビジネス側と結びつける規律
テストはビジネス側の代表者が読み書きできなければならない
p113
全てのテストはシステムの振る舞いを記述する有限状態機械の遷移である
p114
テストダブル: 5つのモックオブジェクト。オブジェクトの代わりを演じているという意味
モックオブジェクトは
- ダミー: 何もしない実装
- スタブ: テストする経路にシステムを仕向けるためにテストに固有の値を戻すダミー
- スパイ: 何が行われたのかを記憶しており、テストから問い合わせることができるスタブ。ただし、テストする関数の実装とテストが結合してしまうため危険でもある
- モック: 何が期待されているのかを把握しており、その期待に基づいてテストをパスまたは失敗させるスパイ
- フェイク: 値に応じて振る舞いを選択できるシミュレーター
p128
TDDの不確定性原理
確定性を求めるならば、テストの柔軟性は低下する。テストに柔軟性を求めるならば、確定性は低下する
ロンドン学派: 確定性が柔軟性より重要と考える
デトロイト学派: 柔軟性が確定性より重要と考える
t_wadaさんの説明を引用すると
モックを積極的に使う派（ロンドン学派）
あまりモックを使わない派（デトロイト学派、古典派）
参照: https://twitter.com/t_wada/status/1448864195357777928
p155
壊れやすい問題は常に計画の問題である
設計が貧弱であることの定義は「小さな変更で多くの部分が壊れてしまう」である
テストはシステムと同じように設計する必要がある
p216
信頼できるテストスイートがあり、素早く実行できるのであれば、より良いアプローチを見つけるたびにコードの設計を改良していける
p236
QAは「完成」を定義する自動化受け入れテストに深く関与しなければならない
p274
良い構造は、良い振る舞いを可能にする
悪い構造は、良い振る舞いを妨げる
構造が良ければ、振る舞いが良くなる
構造が悪ければ、振る舞いが悪くなる
プロの開発者はコードの振る舞いよりも、構造を優先するべきである
p275
アイゼンハワーのマトリクス
重要ではないものはムダだ
上司が期待しているのは、あなたが緊急の振る舞いを実装しながらクリーンな構造を維持することである
まとめ
クラフトマンシップというか、個人的にしっくりくる言葉として「プロ意識」を持って日々の作業を取り組みたいと思う。
駄文
どちらかというと夜型で、早起きは苦手。 早朝にランニングに行くと、かなりの人数のおじいさんおばあさんがウォーキングしてたりランニングしているのである。 尊敬でしかない。夜本を読んだり、ハイラルに冒険に出かけたり、プログラム書いたりしているが、早く寝て朝やるべきなのだろうか。