今日からはじめる 
リファクタリング 
2014.08.30 
kanazawa.rb meetup#24
よろしくお願いします 
• 島津 純哉(しまず じゅんや) 
• DMM.com Labo 
• Linux, Apache, PHP, MySQL, Memcached, 
Javascript, HTML5, Vim, Shell, Git 
@jshimazu0820 Junya Shimazu
こんなコードで困っていませんか? 
• 読みにくい 
• 編集しにくい 
• 複雑
こんなイメージ 
なんで動いてるの?みたいな
コードがモンスター化している!
コードがモンスター化している! 
• メンテナンスしにくい!
コードがモンスター化している! 
• メンテナンスしにくい! 
• 修正したい
コードがモンスター化している! 
• メンテナンスしにくい! 
• 修正したい 
• でも修正するの難しい
コードがモンスター化している! 
• メンテナンスしにくい! 
• 修正したい 
• でも修正するの難しい 
• 現状動いてるので放置・・・
コードがモンスター化している! 
• メンテナンスしにくい! 
• 修正したい 
• でも修正するの難しい 
• 現状動いてるので放置・・・ 
• クソコードが拡大していく
駄目だこのコード、 
早くなんとかしないと・・・ 
リファクタリングをしよう! 
でも、何から手を付ければいいのだろう?
参考文献
リファクタリングの名著 
• リファクタリングを体系化 
• サンプルコードが充実 
• 2000年初版(14年前!) 
• 最近新装版がでた
リファクタリングとは 
「外部から見たときの振る舞いを保ちつつ 
理解や修正が簡単になるように 
ソフトウェアの内部構造を変化させること」 
! 
→ メンテナンスしやすいコードにすること
リファクタリングとは 
「外部から見たときの振る舞いを保ちつつ 
理解や修正が簡単になるように 
ソフトウェアの内部構造を変化させること」 
! 
→ メンテナンスしやすいコードにすること
なぜコードは汚れていくのか? 
仕様追加・変更、バグ修正の繰り返し 
コードがだんだん乱れていくのは自然な事
リファクタリングは 
常に行われていくべきもの
どこを直せばいいの? 
「コードの不吉なにおい」➡22種類 
! 
そのうちよく見かけた5つを紹介
1位 重複したコード
「重複したコード」の特徴 
• 同じようなコードが2カ所以上に存在 
• 2カ所以上変更しなければならない
2位 長すぎるメソッド
「長すぎるメソッド」の特徴 
• メソッドの内部の処理を追うのが大変 
• 一時変数が多くなりがち 
• テスト・デバッグが困難
3位 巨大なクラス
「巨大なクラス」の特徴 
• 仕事をしすぎなクラス 
• いわゆる密結合 
• フィールドが多くなりがち
4位 多すぎる引数
「多すぎる引数」の特徴 
• 引数の意味を理解するのに手間 
• 仕様追加でさらに増える 
• 本来、0~2個にとどめておくのが良い
5位 変更の分散
「変更の分散」の特徴 
• 変更するたびに他の箇所も変更が必要 
• 他方の修正を忘れて問題発生
不吉なにおい=負債 
将来にわたってコードの理解・修正を妨げる 
プログラマーにとっての「負債」
どうやって負債を取り除くか? 
「リファクタリングカタログ」 
わりとすぐに適用できる3種類を紹介
メソッドの抽出
「メソッドの抽出」 
• 最もメジャーなリファクタリング手法 
• コードの断片をわかりやすい名前のメソッド 
にする 
• 「重複したコード」「長すぎるメソッド」 
に有効
クラスの抽出
「クラスの抽出」 
• 本来2つのクラスでやるべきことを 
1つのクラスでやっている場合 
• 「巨大なクラス」に対して有効 
→
委譲の隠蔽
「委譲の隠蔽」 
• 使い手が意識するクラスを2つ→1つに
他にもたくさんあります 
「コードの不吉なにおい」 
「リファクタリングカタログ」 
でググってみよう!
いつやればいいの? 
• 新機能追加・バグ修正・レビューのとき 
• 3度目の法則 
• 不吉なにおい → 1、2回はガマンして 
3回目に感じたときに修正
注意すること 
• 小さい単位で修正・テストしながら進める 
• できれば単体テストコードも用意 
• 機能追加(またはバグ修正)と 
リファクタリングは分けて作業 
• 無理はしない
まとめ 
• リファクタリングは常に行われていくもの 
• 「コードの不吉なにおい」を知る 
• 手法は体系化されている 
「リファクタリングカタログ」
リファクタリングの 
テクニックを身につけて 
幸せなプログラマーライフを!
ご清聴ありがとうございました

今日からはじめるリファクタリング