[読書会]リファクタリング

* 社内向け読書会を急遽思い立って準備
* マーチンファウラーの「リファクタリング」が誤ってもったいない本舗に売ってしまったらしい orz
* とりあえず手元にある本で。
* 大事と思う箇所を自分の言葉で要約していくスタイルで。
* 拙速で準備してるので、間違いがあれば遠慮なく指摘してください。

# エクストリーム・プログラミング 適用編 

* 2002年の本!
* ケンアウアー、ロイミラー

## XPの必須要素(P85)

XPの始祖であるケントベックがプラクティスを12個決めた
そのうち最低限やるべきプラクティスは以下6個がいいよ(と、著者は言っている

* プランニングと見積
* 小さなリリース
* テストファースト
* ペアプログラミング
* リファクタリング
* 継続的インテグレーション

それだけリファクタリングは重要なプラクティスだよ、と。

## リファクタリング(P9)

* 「うまく動きそうな、もっともシンプルなコード」
* 開発が進んで、学習したら(仕様が変化したら)「もっともシンプルなコード」も変わっていく
* `機能を変えずに` コードをきれいに保つ
  * 例: メソッド名を変える、変数名を変える、メソッドの一部を別のメソッドとして切り出す
* 仕様変更を繰り返しても、 システムに手を入れることに対するコストが一定に保たれる(このことはこのページには書いてないけど、XPの重要な概念なので)

![](http://objectclub.jp/community/XP-jp/xp_relate/img/ec.gif)

* システムの寿命を伸ばす

## リファクタリングのコツ(P227)

* `まずテストが前提`
* 新機能追加時に、その機能の関連箇所はリファクタリングのチャンス
* バグ修正はリファクタリングのチャンス

## [話はそれるけど]自動テストの効能 (本からの抜粋ではなく、僕の理解)

* 設計(spec)
* 最小の機能をだけを作るようになる
* レグレッションテスト。デグレードさせない
* リファクタリングの前提条件

## 後の速度をあげる(というより速度を落とさない)(P228)

* 新たなバグを生みにくい、見つけやすい
* パフォーマンスのチューニングがしやすくなる(コードの重複がないから)

## リファクタリングの帽子

マーチンファウラーの本に書いてあったこと。うる覚えだけど書いておく。

* 開発モードと、リファクタリングモードで頭を切り替える、ということ
* 開発モードではリファクタリングしない。汚いコードでもいいからガンガン書く。
* フィラクタリングモードでは、`機能の変更をしない`。コードをきれいにすることだけをやる。
* かぶる帽子を実際に変えながら、自分をコントロールしよう、みたいな話だったと思う。

## リファクタリングすべきとき

* 落ち着かない感じ。「コードが匂う」
* コードを書いたらもっとシンプルにする方法があるかどうかを考える`
* 先延ばしにしない。新しいものを追加したら、必ずリファクタリングしよう(プルリクあげる前にリファクタリング)
* チャンスがあればリファクタリング。進みながらリファクタリング。
* コードを読んですぐに理解できない時はリファクタリングのチャンス。

## [脱線] DRY原則 (達人プログラマー P27)

* DRY - Don't Repeat Yourself
* 開発中の仕様書、プロセス、プログラム中の知識の二重化問題
* `すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならい。`
* 二重化のカテゴリ
  * やむをえない二重化 - 開発者に選択の余地があたえられない - 環境が二重化を要求するような場合。
  * 不慮の二重化 - 情報の二重化に開発者が気づかない場合。
  * 手抜きによる二重化 - 開発者が手を抜き、簡単な方法をえらぶことにより二重化が起こる場合。
  * 開発者間の二重化 - チーム内の別の担当者が情報を二重化してしまう場合。


## [脱線] コードの共同所有(P261)

コードが個人に依存
* その人以外いじりたがらない、その人も手放したがらない
* その人がいなくなると手が付けられない => プロジェクト終了
* ヒーロー = 「一番スマートなトリックを見せる、最高のコードを書いた人」

コードを共同所有
* 誰でもどの部分であっても、より要求に適した、わかりやすい修正を行うことができる
* その人がいなくなっても大丈夫
* ヒーロー = 「最高のペア(コードレビューア)、最高のリファクタリングをした人、周りに最高の勇気を与えた人」

ツール
* コーディング標準
* ペアプログラミングやコードレビュー
* バージョン管理ツール

## リファクタリングすべきではない時(P229)

* 「開発モード」の時
* どうリファクタリングするか、方針がたってない時

## リファクタリングを止める時

* 「十分」は「完璧」にまさる
* 納品が第一の目標
* 「十分」の適当さがわかるのがプロフェッショナル

## [脱線] 「軽量十分」 ( アジャイルソフトウェア開発 P230)

* テストの量、リファクタリングの量、ドキュメントの量
* プロジェクトによって十分と不十分
* やってみて、あとから見直す
* スイートスポットは常に変化するので、常にスイートスポット自体も見直す

## [脱線] 「技術的負債」 ( 1992年ウォード・カニンガム )

> 最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる[2]。

* 僕個人の意見
  * 目的は「ビジネスの成功」
  * 戦略的に借金をし、計画的に返済するのはプロフェッショナルとして十分アリの判断


* [Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming)](https://qiita.com/TsuyoshiUshio@github/items/28f4c127c911170cad49#30-%E8%89%AF%E3%81%84%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%88%E3%82%A2%E3%83%83%E3%83%97%E3%81%AE%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%A8%E3%81%AF)

## 具体的なリファクタリングの手順

* マーチンファウラーの本に載ってたんだが、、、
* こんな感じだったと思う
  * リファクタリングパターンがあるので、ひとつづつ実施
  * 一個直したらテストを走らせてデグレードしないことを確認

## コードの匂い

https://refactoring.guru/refactoring/smells

いくつか抜粋

* [Comments](https://refactoring.guru/smells/comments)
* [Duplicate Code](https://refactoring.guru/smells/duplicate-code)
* [Dead Code](https://refactoring.guru/smells/dead-code)
* [Long Method](https://refactoring.guru/smells/long-method)
* [Large Class](https://refactoring.guru/smells/large-class)


## テクニック

https://refactoring.guru/refactoring/techniques

いくつか抜粋

* [Rename Method](https://refactoring.guru/rename-method)
* [Extract Method](https://refactoring.guru/extract-method)
* [Inline Temp](https://refactoring.guru/inline-temp)