リファクタリングプログラミングの体質改善テクニックを読んで

リファクタリングプログラミングの体質改善テクニックという本を読んだ。

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

作者:マーチンファウラー
ピアソンエデュケーション

Amazon

なかなか面白かった。特にリファクタリングとは何かを説明する前半部分が参考になった。後半部分は様々な方法を述べているだけなので、必要に応じて読めばいいと思う。

いつもどおり特に心に残った部分を書いていく。

分かりやすいコード

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

リファクタリングのリズム

テスト実行 -> 少しの変更 -> テスト実行 ...というリズムで書いていくといい
1ステップのリファクタリングをして、これまでの挙動と変わっていないかテストなりで確認する
大きな変更を一気に加えるとどこでバグが起こったかわからなくなる

リファクタリングと機能追加の二つの帽子

リファクタリングと機能追加を同時に行なってはいけない
- リファクタリングをして挙動が変わっていないかなどがわからない
小さな単位でテストをしつつ次々と切り替えるのは良い
確かに最近そっちのほうがうまくいくことが多い
- あるControllerに少しだけ機能追加(この時点で同じようなコードが他にあることがわかってる)
- テスト追加して通ることを確かめる
- その後に同じようなコードをメソッドの抽出などを使ってリファクタリング
- というふうにしたらスムーズに機能追加とリファクタリングが出来た

まとめ

最近は複数人でコードを書くときにスムーズにいくようにはどうすればいいかひたすら考えてる。そのためにこの前書いたコードコンプリートを読んだり、リファクタリングの勉強をしたり、ペアプロの勉強をしたり、XPの勉強をしたり、いろいろしている。

思ったこととしては、この辺りの勉強は面倒だけど仕事でプログラムを書くなら早めにやったほうが良いということ。エンジニアだったら新しい技術のほうが楽しいと感じるだろうし、もちろんそれに飛びつくのもいいと思うけど、この辺りの勉強もしておかないと、ひとりよがりなコーディングをして、その後そのコードを触る人に迷惑をかけてしまうように感じる。

とは言え新しい技術をキャッチアップしないというのも良くないと思うので、息の長い技術と最新の技術を合わせながら勉強していこうと思った。

次はペアプロの本とか読もうと思ってる。