「テスト駆動開発」の書籍のコードを写経したので、感想書きますね。(写経1回目)

## 概要
[テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C)の書籍を購入して、一通り読みました！
翻訳者の和田さんが写経をお勧めしていたので、実際に１回、eclipseで環境整えて写経してみました。
その感想とか書いていきます。

## なんでこの書籍読んだの？
よくエンジニアは、TDDで開発したいという。
「ほへぇ〜TDDってなんですか？」って聞くと、「テストから開発する手法だよ〜」みたいな返答が返る。
詳しいことは教えてくれない。そして結局TDDで開発しないで有耶無耶になる。
なので、「テストから開発しなくても開発できるし、テストは後で書けばいいよね！」と思い、そんな興味を持っていなかった。

そんなある日、弊社で週に１回行われるエンジニア会で、和田さんの「[見てわかるテスト駆動開発](https://www.youtube.com/watch?v=Q-FJ3XmFlT8&t=880s)」をメンバーで視聴しました。
コードが出来上がっていく過程をみて、TDDで開発すれば、自身を持ってコードが自分の思い通りに動く気がし、学習してみようと思いました。
動画の中で和田さんが「[テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C)」の書籍をお勧めしていたので購入してんだのがきっかけです。

## 写経とは？
実際に本に書いてあるコードを、実際に自分で逐一入力して、その流れに沿って打ち込んで実行していくことを、「写経」と読んでいるそうです。
[テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C)の書籍には、実際にコードが出来上がっていく過程が、事細かく記載されています。
そのコードを実際に入力して、実行してTDDに関して理解を深めていくということらしいです。

## 写経の手順
[テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C)の書籍には、以下の手順で、写経をすることお勧めしています。
1. ローカルで使えるバージョン管理システム(Git等)を用意。
2. 書籍台などで対象の本を固定(あるいは、電子書籍を開く)。
3. ひたすらサンプルコードを写して実行。
4. 実行するたびにコミット（コミットログにページ番号を含める）。
5. 疑問点があったらコミットログや本に書き込む。
6. 章ごとにタグを打つ。

今回の写経では4と6は面倒だったので、行いませんでした。
4を行わなかった理由は、途中でコミットするの忘れたので、やめました。
6を行わなかった理由は、単にコマンドでタグを打つのが面倒だったからです。

最終的にはこんな感じになりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/702045/dbbc6577-5a78-8239-bc4f-dcccb8641a59.png)

トータルで4Hほどだった気がします。

## 写経してみて
今回、写経したのは、「[テスト駆動開発](https://www.amazon.co.jp/dp/B077D2L69C)」の書籍に記載されている、「**多国通貨**」のコードを写経しました。
その感想をつらつらと書いていきます。

### 書いたコードが消えていく
写経時に、過去に書いたコードがどんどん消えて新しいコードに書き変わります。
掘った穴を埋め戻すようなことを度々行うので、精神的に苦痛なときもあります。
完成させるためにコードを書いているのではなく、TDDの学習のために書いているのだと意識しなければ、放り投げていたかもしれないです。

### コミットログにやったことと分からなかった書くと理解した気になれる
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/702045/ee2c610d-e460-fc45-b0ec-b93520f2768b.png)
学校で黒板をノートに写していると、理解していないけど分かった気にはなるあれですね。
コミット毎に達成感はあります。
もしかしたら、TDDで開発を進めた時に、このコミットが満足感というか達成感に繋がるのかなぁと思いました。

### TDDでコードが出来上がる過程が良くわかる
TDDのサイクルが分かってきます。
写経するうちに、「次は多分コンパイルエラー無くすんだろうなぁ〜」とか、
「リファクタするんだろなぁ〜」とか「テスト書くんだろなぁ〜」と思うようになりました。


### テストから書くことの難しさを感じる
今回はKentBeckさんがTODOリストを作ってテストを書いてTDDによる開発を体験しましたが、
実際に、あまりテストを書いたことがない私にとっては、このTODOリストを作成するのが難しそうだと感じました。
何のテストを実行すれば、自身を持てるのか。それを考えたことはあまりないので慣れが必要な感じがします。

また、実装中に出てくるTODOリストの漏れ事項をTODOに追加することがあるのですが、それをTODOのリストと理解して追加することができるのか不安です。

### 仮実装の背徳感がすごい
テストを通すために、最短のルートで実装を行うのですが、これがなかなか慣れないです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/702045/5eff0af0-dcb5-b530-fe22-a78dd5ed1363.png)
頭の中では実装が終わっているが、それを無視して仮実装する難しさ。
仮実装のステップを飛ばしたい気持ちになります。飛ばしてもいいのか・・・？

### グリーンバーを出しながらリファクタするのは安心する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/702045/7db9684c-9d2b-559d-278e-e6cc7e5c5baf.png)
200回はテストを回したと思います。
ちょっとリファクタしてはテストを実行し、ちょっとリファクタしてはテストを実行し・・・。
グリーンバーを出しながらリファクタリングを行うのは、精神的に安定します。
200回マウスで実行するのが面倒だったので、テストを実行するショートカットキーも覚えました。

### 後半リファクタリングの時、何をしたかったのか忘れる
思考停止して写経する時が多々ありました。（`Expression.java`が出始めた頃から）
理由を考えたところ・・・・
- KentBeckさんが何したいのか、何いってんのか、多分分かっていない
- 思った以上に消しては書き、消しては書きを繰り返すため、「何してたんだっけ？」となる

KentBeckさんが何したいのか分からない時は、思考停止して写経することをお勧めします。
コードを記述する前に、今から何をするのか記述されているのですが、何度読み直しても良く分からないことが多々ありました。
悩まず、思考停止して写経すれば、後から「そういうことね！」ってなりました。
そういう意味では、写経は１回ではなく複数回やったほうがいい気がしましたし、一読した時、理解していなかった事を痛感しました。

リファクタリング中に「何してたんだっけ？」となった場合、後半から気づきましたが、そんな時は、テストに何を書いたか見直すと良いです。
基本的にリファクタリングはテストに書いたコードを元に実装しているので、テストを見れば何をしていたのか思い出します。

## まとめ
「**多国通貨**」を写経してみて、TDDへの理解が深まりました。
1回では、モヤモヤは拭えないので、もう一回、写経しようかと思いました。
また、TDDは実際に手を動かさないと理解しにくいものだと感じました。
TDDを理解したい人は是非、写経しましょう。