第２章リファクタリングの原則リファクタリングの原則

2012/02/06CyberX　エンジニア　石川泰式

リファクタリングの原則

• リファクタリングの重要な原則を改めて振り返り，リファクタリングを実践する上での考慮点について見て行く．

リファクタリングの定義（１）

• リファクタリング（名詞）• 外部から見たときの振る舞いを保ちつつ，理解や修正が簡単になるように，ソフトウェアの内部構造を変化させること

リファクタリングの定義（２）

• リファクタリングする（動詞）• 一連のリファクタリングを行って，外部から見た振る舞いの変更なしに，ソフトウェアを再構築すること

２つの帽子

• ソフトウェア開発でリファクタリングを使うときには，２つの活動に作業を区分すべき

２つの帽子（１）

• 機能追加• 既存のコードを変更してはいけない• 機能を拡張することに専念する．• 作業の進度は，テストの追加と正常な実行結果によって測れる．

２つの帽子（２）

• リファクタリング• リファクタリングをしている時は，機能追加は行わない

• 原則としてテストの追加はしない

２つの帽子（まとめ）

• コードの構造がよくなったところで，機能追加を行う．

• 重要なのは，どちらの帽子をかぶっているかを常に意識しておくこと

リファクタリングを行う理由

• リファクタリングがすべてのソフトウェアの問題を解決するわけではない

• 「銀の弾」は存在しない

設計の向上

• リファクタリングなしでは，プログラムの設計は徐々に劣化する．

• 設計のまずいコードは，余計にコードを書くことになる．

• 重複の排除は優れた設計のポイント

ソフトウェアを理解しやすくする

• 何を意味しているかを正確に表現することが重要

• コードの不明な部分を理解するのに役立つ

• より深いコードへの理解を得られる．

バグを見つけ出す

• コードが理解出来るようになると，バグが見つけやすくなる．

• 「僕は，偉大なプログラマなんかじゃない．偉大な習慣を身につけたプログラマなんだ．」 (Kent Beck)

より速くプログラミングできる

• 間違った設計でもしばらくは順調に開発できる．

• やがて設計のまずさが徐々に足をひっぱるようになる．

• リファクタリングが設計の劣化を防ぐ

いつリファクタリングすべきか

• リファクタリングは時間を決めて行うような活動ではない

• 何かを行うための手段としてリファクタリングが行われる．

３度目の法則

• 最初は単純に作業を行う．• ２回目では重複や無駄を意識しつつも，とにかく作業を行う．

• ３度目同じようなことをしていると気づいたらリファクタリングする．

リファクタリングのタイミング

• 機能追加時にリファクタリングを行う• バグフィックスの時にリファクタリングを行う．

• コードレビューの時にリファクタリングを行う．

コードレビューについて

• 開発チームに知識を浸透することができる．

• 経験者による知識の共有• アイデアを引き出せる．• レビューは少人数で行うべき

プログラムの２つの価値

• 今何ができるのか• 将来何ができるようになるのか

理想的なプログラムとは

• コードが読みやすい• １ヶ所にのみロジックが書かれている• 既存の動作に影響を与えない• 条件分岐が簡潔に表現できている

管理者の説得方法

• 品質を気にする管理者なら，品質向上を強調する．

• スケジュールを気にする管理者なら，黙ってやる．リファクタリングすることにより開発速度が上がる．

間接層とリファクタリング（１）

• 「コンピュータサイエンスは，間接層(indirection)を設けることであらゆる問題が解決できるという信念に基づいた学問である．」（Dennis Debruler）

間接層とリファクタリング（２）

• ロジックの共有を可能にする．• 図と実装を独立して説明できる．• 変更を分離する．• 条件分岐をポリモーフィズムで表現する

リファクタリングの問題点

• データベース• インターフェースの変更• メソッド名を変更した場合は，古いメッソドを削除せずに，内部で新しいメソッドを呼ぶように変更する．

リファクタリングしにくい設計（１）

• リファクタリングが容易な場合• あまり検討に時間をかけずに，とにかく単純な方法を採用する．

• 将来的な要求の可能性をすべてとらえきれていないとしても気にしない

リファクタリングしにくい設計（２）

• リファクタリングが困難な場合• 時間を掛けて検討する．

リファクタリングと設計（１）

• リファクタリングには，設計を補完する役割がある．

• 思いつくままコーディングして，ともかく動作させ，その後リファクタリングで形を整える．

リファクタリングと設計（２）

• 「設計時には，順調に思考が進みますが，それは隙だらけなのです」 (Alistair Cockburn)

• すべてにおいて柔軟性を実現しようとすると，ソフトウェアが過度に複雑化し，保守が難しくなる．

リファクタリングと設計（３）

• リファクタリングは，柔軟性を損なわずに設計をシンプルにする．

• リファクタリングを簡単に行えるという感覚が身につけば，柔軟な解決策をむやみに求めなくなる．

何も作り出さないことにかけた時間

• システムが行っていることを十分に分かっているつもりでも，推測はやめて，まず実際に計測をすること．そこで何が本質かをつかむこと．十中八九，あなたの推測は間違っている．

リファクタリングとパフォーマンス（１）

• ソフトウェアを理解しやすくするための変更は，しばしばプログラムの実行速度を落としてしまう．

リファクタリングとパフォーマンス（２）

• ホットスポットに集中してパフォーマンスを改善する．

• 改善されなかった変更は元に戻す．• ユーザの満足する水準に達するまで，ホットスポットを見つけては退治していく．

リファクタリングとパフォーマンス（３）

• 設計が明確なため，より速く機能改善でき，その分，最適化に割ける時間も増える．

• プログラムの設計が優れていると，パフォーマンス解析の際，より細かな単位へ集中することが可能になる．

まとめ

• リファクタリングは銀の弾ではない．• リファクタリングは運用・変更をしやすくする為の方法