（読書メモ）リファクタリング -プログラミングの体質改善テクニック-

コンパイラが理解できるコードは誰にでも書ける。すぐれたプログラマは、人間にとってわかりやすいコードを書く。

現場の経験が不足している自分みたいなペーペーが読んでも理解できるか疑問ですが読んでみました。

本書について

日進月歩の情報技術の世界では、10年前の本なんて陳腐化している。Amazonマーケットプレイスでは1円で投げ売りされるものも多い。けれど、これは違う。マーチンファウラー御大のこの本は1999年に出版されたという古さにもかかわらず、いまなお読み継がれている。これはAmazonでの高い評価と、マーケットプレイスでも価格が2割も下がっていないという事実からも窺える。
ひどいシステムに翻弄されているなかでいいプログラミングを書きたい人は多いと思う。この本ではそのためのテクニック「リファクタリング」を解説している。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリングの原則

リファクタリングの定義

外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること

すでに動いているものを、機能追加でもないのになぜ手を加えるか。

リファクタリングの目的

• 設計を向上させる
• ソフトウェアを理解しやすくする
• バグを見つけ出す
• 速くプログラミングできるようになる

もちろん機能追加にならないのでマネージャや顧客を説得するのは難しい。
けれど長期的には開発コストが下がる（はず）

いつリファクタリングするか

• 不吉な匂いを感じたとき
• 機能追加時・バグフィックスの際
• コードレビュー時

ただし、バグ改修とリファクタリングを同時に実施してはいけない。
かえってバグを埋め込む危険があり、あとあと改修しにくくなる。モードを切り換える必要がある。
（バグ改修のコミットと別コミットとするべきか）

どうリファクタリングするか

• リファクタリングをする際にはテストを用意しておく必要がある
• 小さく直して、確認していくサイクルをつくる
• わかりやすくするための変数名の変更に躊躇はしない

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

• リファクタリングは直接にはパフォーマンスを改善しないが、パフォーマンス改善を実施しやすくする
• 一般には、設計初期はあまり性能について考えず、ある程度できてから計測してボトルネックに対応するのがよい（もちろん例外もある）

単体テスト

• 単体テストはプログラマの生産性を向上するために行うもの。
• 品質保証のためにはソフトウェア全体の動作を保証するための機能テスト（結合テストとか言われるもの？）が必要。
• 結合テストでバグをみつけたら、それを取り除くのはもちろんだが、バグを明らかにするための単体テストを追加するべき

リファクタリングの手法

80ほどの具体的な手法がカタログ的に説明されている。全部は読んでいないけれど、オブジェクト指向なパターンにするのが多いように感じる。

共通する処理を取り出す。引数が多いメソッドの対処。クラス関連を単方向にする。条件分岐をポリモルフィズムでシンプルにする。など、よく聞くな、というものもあるけれど、初めて知るものも多い。

詳細は下記の公式ページが参考になる。
Alpha list of refactorings

気になるのがあれば追記していくよてい。

気になること

あまり本書に書いてなさそうで気になること。今後の課題

• リファクタリングと並行してテストを書き換えていく必要がありそう
  • 回帰テストはどうやるのがいいんだろうか
• データベーススキーマのリファクタリング
  • 最初に慎重に設計してもどうしてもあとで改善点が出てくる。けれど、一度決まって使われてしまっているスキーマはなかなか直せない・・・
• 大きなチームで開発しているときのリファクタリング
  • どうしたらいいんだろ。レガシーコード改善ガイドに頼るべきかも。
  • ウォーターフォールに組み込むのは難しそう・・

感想のメモ

• リファクタリングは、すでに動いているものを直す、という事後的なものに感じられる。けれど、これを読み、どうリファクタリングすべきか、という知見は設計プロセスの考え方としても使えると思った。
• プログラムをリファクタリングすることで設計を改善していくという、ウォーターフォールの設計→製造とは逆の流れがあるように思える。設計とプログラミングのプロセスは不可分とはよく聞くけれどここまでやるのか。
• リファクタリングを通してペアプロしてノウハウを共有していくチーム・開発スタイルに憧れる・・。おしごとで触っているシステムをリファクタリングするのは難しい。けれど、役立たせたい・・・。

あと、これは自分の主観だけど、多くの会社はシステム開発を発注する際、そのときの受注価格ばかりに注目して、そのあとの保守コストにあまり気を遣っていないように思える。
ふつうにシステム開発がぽんぽん失敗している中ではそんな先のことを考えるのは捕らぬ狸のなんとやらかもしれない。けれど、ただ安いからとオフショアで発注して、その結果、表面的に機能要求は満たしているけれど中身がクソすぎて、あとあと保守したり機能追加することになる現場が死ぬみたいなことがある（らしいですよ）。なんなんですかJavaなのに500行越えるメソッドって。コピペみたいなコードが散見されるんですがなにこれ・・・。そして開発担当したその会社でしか追加修正できないみたいなことになって結果として割高になるみたいなことになる。
リファクタリングするかどうかはさておき、システムを発注する側も開発する側も、保守性をもっと考えたほうがよいと思う。

ただ、動いているコードに手を加えるのは怖いし責任問題になってしまう。長期的なメンテナンスを考える必要があるけれど、リファクタリングにお金や人員・時間を割くようマネージャ・顧客を説得するのは難しい。根拠となる数字も出せないし。どうしたらいいんだろ。いいやり方しっている方がいれば教えてください。

参考

• はてなは「絶対すべきでないこと」をやらかしたのか？
  • リファクタリングとは違うけれど、システムを新しく書き換えるかどうか
• 「綺麗なコードでも汚いコードでも，動くコードは正解だ」．しかし汚いコードは動かない． - カレーなる辛口Javaな転職日記
  • 汚いソースのリスクについて
• 沈没船エントリのあとがき
  • リファクタリングの難しさについて言及している沈没船からのメッセージ

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコードと対決する際の攻略本。
ちょっとだけ読んだけれど、ちゃんと読んで使えるようにしたい・・・

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

3年くらい前にまわりで流行った本。自分の生活もリファクタリングしよう。