More than 3 years have passed since last update.

株式会社ビー・アジャイル

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

Last updated at 2020-09-25Posted at 2020-09-16

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

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

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

XPの必須要素(P85)

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

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

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

リファクタリング(P9)

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

システムの寿命を伸ばす

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

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

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

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

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

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

リファクタリングの帽子

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

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

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

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

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

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

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

コードが個人に依存

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

コードを共同所有

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

ツール

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

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

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

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

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

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

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

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

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

僕個人の意見
- 目的は「ビジネスの成功」
- 戦略的に借金をし、計画的に返済するのはプロフェッショナルとして十分アリの判断
Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming)

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

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

コードの匂い

いくつか抜粋

テクニック