テスト駆動開発が良書だということは聞いていたので、読むことにしました。
第7版の増版が決まったそうですごい…。
結論を先に記載すると、ほとんどのエンジニアは読むべき良書でした。
誰が読むべきか
読むべき
- 初心者
- 自社サービスを持っているエンジニア
- ライフサイクルが長いプロダクトに関わっているエンジニア
- アジャイル
- 修正が多い
エンジニアリング能力が低いと、安心して修正ができないです。
蛮勇ではなく、勇気をもった修正を行いたい人は読むべきでしょう。
読まなくてもいい
- リファクタリングに興味が無いエンジニア
- フルスクラッチのみのウォーターフォール開発
- プロダクトライフサイクルが極端に短いプロダクト
- 追加開発がないので、修正を行わない
機械的にできるリファクタリングもありますが、構造を大改造するようなリファクタリングには不安が伴います。
なので、「リファクタリングしない = 不安と戦わない」エンジニアは実践しないので、読んでも効果は薄そうです。
フルスクラッチでも活かすことはできますが、不安と戦うのはどちらかというと追加開発で修正を加えるほうでしょう。
エンジニアとしては、事実上ありえないので、9.9割くらいのエンジニアは読むべきです。
本の名前とURL
テスト駆動開発
感想
丁寧な進行で解説されていきます。
原書はわかりませんが、かなり写経がしやすい本でした。
第1部他国通貨 、第2部xUnitに関しては以下の流れで記載されています。
- 章頭でTODOリストを確認。
- 何を解決したいかを確認。
- 思考も記載しながら、本当に小さいステップで解決する。
- 章末にコードが記載されています。
変化の過程のコードは記載されていても、最終的にどのような形になっているのか不明なコードがたまにあります。
この本では、章末にコードが記載されているので、章ごとのゴールが非常に追いやすかったです。
また、TODOリストの追加方法、分解方法そしてTODOリストの運用を学ぶことができるのは、地味ながらメリットです。
普通に開発していたらペアプロでもしないと仕事の仕方は覚えられないので、この本で覚えられるのは良い点です。
まえがきでも、ペアプロを意識していると書いてありました。
上級者が初心者に、まるでその場にいるように教える形式になっています。
第1部、第2部は論理立てて話は進んでいきますが、設計としてはかなりの高難易度になっています。
一通り読んだ後は理解しましたが…。
第10章くらいから書籍だけでは理解ができなかったので、写経しながら読むことにしました。
なので、写経しやすい本の形式でありがたかったです。
自分が1からやれと言われて、同じように導ける気はしませんが。
でも、難易度が高いからこそ、安心して開発するためのTDDだとわかります。
TDDであれば、「勇気をもって開発できる」ということが非常にわかりやすいです。
第3部テスト駆動開発パターンについては、各章が独立しているので前から読んでいく必要はありません。
第1部・第2部と違って、抽象的な話が多くなるので、私は理解できたとは言えません。
一旦知識として仕入れておいて、半年・1年後に再度読むことで腹落ちすることでしょう。
「付録C訳者解説：テスト駆動開発の現在」は、必読です。
2017年時点での話なので既に幾つかは過去のものとなっているでしょうが、TDDの捉えられ方の変化がわかります。
「TDDは死んだ」がどのような問題提起かを理解していなかったので、非常に勉強になりました。
あと、私はt_wadaさんの登壇資料を見て写経をしましたが、本でも写経を薦めておりました。
その他気になったところ
P159に記載されている以下の一文。
手戻りを嫌って、3箇所か4箇所重複が発生するまでリファクタリングを待つという人もいる。 私は試行サイクルを設計に使いたいので、すぐに戻す可能性を気に留めず、反射的にリファクタリングしてしまう方が好きだ。
実際、ほとんどのエンジニアはどのくらいの重複までは許してるんでしょう。
原著者のKentBeckさんは2アウト、訳者の和田さんは3アウト制を敷いているようですね。
TDDは誰でも訓練で得られるスキルらしいので、慣れるまでは2アウト制で設計力を磨いていった方がいいかもしれません。
「毎回、本のような綺麗な設計ができるのであれば、そりゃあ楽しいでしょうね…」
という感想もありますが。
その他気になったところ2
前者より後者の方がテストとして、表現ができているからよいという話もありました。
new Sum(10)
new Sum(15/5 + 5)
ただ、個人的には後者だと混乱しそうなので、できるだけ具体的な前者の方が良いテストだと思ってしまいます。
前者でテストしておいて、あとあとリファクタリングで後者に寄せていくのがいいんでしょうか…。
logとか16進数変換とか、日付減算とか私はすぐ出てくるタイプじゃないので、苦手です。
懺悔
これは私がサボった点なので本とは違う点です。
写経する際に本と違う内容を書いてしまうと後の説明が正しくならないので、正確に写経しないとダメですね。
とりあえずpublicにしてしまう癖とか、equalsやhashcodeはlombokでやってしまう等々。
特にDollarとFrancをMoneyに統合する過程で、intellijの機械的なリファクタリングに任せてしまったので、superクラスを呼び出すようなコードになってしまいました。
個人的には設計上、これでも別に問題はないと考えてますが、本が行う設計の導き方とは違ったので地味に苦労しました…。
写経するなら、余計なことしちゃだめですね。
// ※ 本の通りに写経しなかったコード public class Dollar extends Money{ Dollar(int amount){ super(amount, "USD"); } } public class Franc extends Money{ Franc(int amount){ super(amount, "CHF"); } } public abstract class Money{ private int amount; private String currency; Money(int amount, String currency){ this.amount = amount; this.currency = currency; } }
まとめ
2020年になっても通用する良本。
エンジニアならみんな読むべき。
少なくとも、第1部 他国通貨はJavaエンジニアであればinterfaceやら、abstractの使い方も覚えられるので写経すべき。
