📝

技術書読書ログ「Clean Craftsmanship」

2023/02/01に公開

技術書

TDD

idea

個人的に重要だと思ったところ

サマリ

クラフトマンなプログラマーには「規律」「基準」「倫理」がある。
規律が基準や倫理を支える(守る、満たす)ためのベースとなるもの。
その規律の中でも要となるものはテスト駆動開発（TDD)である。

クラフトマンとは

特定の分野に関する高度なスキルを持ち、物事を成し遂げる人。
仕事に誇りを持ち、プロ意識があり、信頼されている人。

倫理

プログラマーとしての「誓い」「約束」

害を与えない
- 有害なコードを作らず、常に最高傑作で正しく動くことを証明したコードをリリースする
誠実である
- 誰かの進捗を妨げないように小さく何度もリリースする
- あらゆる機会で、容赦無く改善する(決して劣化させることはしない)
- 自分や誰かの生産性を高めるためにできる限りのことをする(決して誰かの生産性を落とすことはしない)
チームに対するコミットメント
- 自分が他の人をカバーできるようにするだけでなく、他の人が自分をカバーできるようにもする
- 正直に公正に見積もり、不確実な間は約束しない
- 仲間の規律・基準・倫理・スキルを尊重する
- 学習し続け、自分のスキルを向上し続ける

基準

世界(プログラマー以外の人)がプログラマーに期待していること。その期待のベースラインであり、上回ることはできるが、下回ることは許されない。

安定した生産性 : 変化に強い。常に準備万端にしておく。
高い品質 : 継続的な改善で品質を保つ。そのためのテストとリファクタリング。
勇気ある言動 : 倫理のチームに関する部分とほぼ同じ。

規律

プログラマーのルール。優れたアジャイル手法である「エクストリームプログラミング(XP)」のエンジニアリングプラックティスがそれにあたる。
具体的には「テスト駆動開発」「リファクタリング」「シンプルな設計」「協力的プログラミング」「受け入れテスト」の5つ。

テスト駆動開発が規律の要

テスト駆動開発は、「信頼できるテストコード」と「適切に分離された本番コード」をもたらしてくれる。これらはリファクタリングをやりやすくし、そしてリファクタリングがシンプルな設計を可能にしてくれる。

また、生産性を高めてくれたり、継続的な改善がしやすく品質を高めてくれたりするなど、テスト駆動開発によって満たせる基準や倫理は多い。

テスト駆動開発のテクニック

テストの設計について

テストを壊れにくくするため、テスト構造を本番コードと分離する(結合度を下げる)。具体的にはテストと本番コードは1対1の関係にはせず、ファサードのようなモジュール経由でテストする。

テストダブルについて

前提として、テストに確定性を求めると柔軟性は低下する。逆に柔軟性を求めると確定性は低下する。なので適切なトレードオフを行う必要がある。

ロンドン学派は柔軟性よりも確定性を重視する考え方で、シカゴ学派は確定性よりも柔軟性を重視した考え方。どちらが正しいとかはなく両方の技術を使って適切に選択することが必要。

著者(アンクルボブ)の戦略としては、テストがアーキテクチャの境界線を越えるときはロンドン学派になり、そうでないならシカゴ学派なテストを書く。
※アーキテクチャの境界線とは、システムを複数のコンポーネントに分割した際の、コンポーネントとコンポーネントの間のこと。

変換の優先順位について

新しいテストケースを追加するたびに、テストスイートは具体的になっていくが、本番コードは一般化していく。この本番コードを一般化させる際の本番コードの変換には以下の方法がある。

{} -> Nil
Nil -> 固定値
固定値 -> 変数
無条件 -> 選択
値 -> リスト
文 -> 再帰
選択 -> 反復
値 -> 変異値

この優先順位で変換を進めると、良い実装になる可能性が高い

感想

テスト駆動開発に関する解説やテクニックが多く載っていたり、他の章や項目でもテスト駆動開発は大事だと挟んできていて、肝なんだなとうのが伝わってくる。

個人的にはテストコードに関する考え方が、前回記事にした「単体テストの考え方/使い方」と似ていて、より理解が深まったと思う。

一番、興味深かったのが「変換の優先順位」。ちょっと手間にも思えてしまうけど、この順でやって良い実装に導かれるというのがどれくらい有効なのか体感してみたい。