動作するきれいなコード: SeleniumConf Tokyo 2019 のまとめ

# 概要
和田卓人さん(t-wadaさん)の[ブログ](https://t-wada.hatenablog.jp/entry/clean-code-that-works)の公開されているYoutubeをみたら、ためになりました。
昨年度の講演ですが、まとめた記事です。

# テスト駆動開発の本
書籍「テスト駆動開発」は、テスト駆動開発を作ったKent Beckが書いた唯一の本であり大事。

# テスト駆動開発のゴール
> Clean code that works

動作するきれいなコード

# ゴールに行き着く為に分割統治する
**Clean code**と**that works**に分割統治する。

２通りの行きつき方がある

* cleanにしてから動かす
* 動かしてからcleanにする

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/199256/4a816da3-5c10-09b2-a3c6-90b42f64dcb4.png)
(和田さんの[スライド](https://t-wada.hatenablog.jp/entry/clean-code-that-works)より)

## Cleanにしてから動かす
きちんと設計をして、動くコードを書くのは設計ができてからという考え方。
昔はこちらの考えが大勢を占めていた。

設計してから動かすことには沼がある。

|||
|---|---|
|羞恥心|他の人に見せるには至らないな|
|虚栄心|文句のない設計にしてやろう|
|完璧主義|対象の領域について考えきれていないのでは？もっと極めないと|

良い設計とは何かを考え続けると無限の罠が広がっており、これをプロジェクトマネージメントでのアンチパターン **Analysis panalysis**(完璧主義の呪い)という。

時間が来て設計を終了し、「コードを書かないと」となる。そこですごくフィードバックが出てくる。

* 設計は過剰だったのでは？
* 細部まで考えられていなかった。
* 動かして見たらパフォーマンスの問題があった。


ソフトウェアは動かすまでわからない(**予測可能性**と**再現性**が高くない)
5年前のソフトウェアはそのままでは動かない。他が変わってしまっているから。

**コードを動かすのが遅れるほどリスクを抱える**

## 動かしてからCleanにする
上よりもこちらの方がましでは？

動かしてからきれいにすることにも沼がある

|||
|---|---|
|怠惰|動くからいいじゃない|
|焦り|きれいにしている時間がない！|
|恐れ|動くソフトウェアをきれいにして動かなくなるのが怖い。。。 (動くコードに触れるな！)|

現代だとコードに触れないとupdateで動かなくなる。
単純にビジネスで勝てなくなる。他の会社はどんどんコードに触るから。

ほっとくと動かなくなるのがソフトウェア業界

edit and pray: 爆弾処理のようなことがやりたいわけではない。
cover and modify: 破壊的なことにはならず手を入れられるソフトウェアを作りたい。

**エンジニアは道具と技術を持って恐怖に対抗すべき**

**触り続けられるソフトウェアに価値がある**

# ソフトウェア開発３つの技術的な柱(３種の神器)
競争力を得るというより、ないと競争力がなくなる当たり前のもの。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/199256/e9166d8a-10a5-555d-fd26-090d7d5e3b99.png)

||補うもの||
|---|---|---|
|Version Control|人間の記憶力|1ヶ月前の詳細はわからない。Version管理システムが覚えてくれる。Version管理システムの使い方だけわかれば良い。|
|Testing|人間の把握力|前動いていた機能が動くかわからない|
|Automation|人間の忍耐力|人間は繰り返しが苦手 -> さらなる進化の`Autonomation(自働化)`おかしなところがあれば機械から教えてくれれば良い|


トヨタ生産方式の考え方
[XFD](http://objectclub.jp/community/xfd/)(eXtreme Feedback Device) = トヨタ生産方式における行灯
機械の割り込み方を工夫する。

# Refactoring
外部からの振る舞いを変えずに整理する

どのようにリファクタリングでコードが動かなくなる恐怖と闘うか？

* 成功するテストの失敗(Testing)によって動かなくなったものを検知し、機械がそれを自動的に行う(Automation)。間違っていたらVersion管理システムで戻す。

# 大事なのはフィードバックループのサイクルを回し続けること
テスト駆動開発は、テストとリファクタリングを両輪としてフィードバックループを回し続ける。

矢印が単一の目的を持ってきちんと回転しているのがテスト駆動開発の強さ。

![TheGoldenCycleOfTDD](https://cdn-ak.f.st-hatena.com/images/fotolife/t/t-wada/20191225/20191225133923.png)
(和田さんの[スライド](https://t-wada.hatenablog.jp/entry/clean-code-that-works)より)

## Refactoringは弱い
外的内的要因の**焦り**により後回しにされやすい。しかしRefactoringタスクは着手されなかったり完了されない。
放置すると3分で終わったものが2日がかりとかになってしまう。


Refactoringは日々のタスクにしないとダメ(**Refactoringを一人にしない**)。コーディングの中に入れてしまえるくらいに小さくする。ここがテスト駆動開発の隠れた良い点である。

良いソフトウェアであり続けるプロセスは自己相似形のループとなる(Planning/Feedback Loop)
サイクルには回転半径があり、速さや目的が異なる。

![](https://cdn-ak.f.st-hatena.com/images/fotolife/t/t-wada/20191225/20191225134028.png)

# ユニットテスト
自分たちのコンテキストで各大きさのテストを定義すると良い。

# テストの指標
## F.I.R.S.T

* Fast
* Independent
* Repeatable
* Self-Validating
* Timely: 書かれるべき時に書かれる。テスト駆動開発はこれを直前と考える

## A-TRIP

* Automated
* Thorough
* Repeatable
* Independent
* Professional: テストコードだからコーディングレベルを下げて良いわけではない。テストのメンテナンスに時間をかけることになってしまう。


## 2つの指標で交差している部分
RepeatableとIndependentは共通であり。
独立と再現可能性というのは最も大事。

# 終わりに和田さんの好きな部分
> テスト駆動開発は、設計のひらめきが正しい瞬間に訪れることを保証するものではない。しかし、自信を与えてくれるテストときちんと手入れされたコードは、ひらめきへの備えであり、いざひらめいたときに、それを具現化するための備えでもある -- Kent Beck

#　まとめのまとめ
* コードを動かすところでフィードバックがあるので、早めに動かす方がリスクが低い
* ソフトウェア開発の3つの柱を使い、エンジニアは恐怖に対応する
* コードに触れてフィードバックループを回し続け、ビジネス上の競争力を維持する
* リファクタリングはコーディングに組み込む
* 自己相似形のフィードバックループ。テストの大きさはチームで定義する