refactor


※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

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

なんだかんだ言っても10年前の本なので注意。


1週目:付箋付け。

・ローカル変数がリファクタを難しくするという発想を得た。

・今まで、副作用イヤイヤ脳だったのが、

せっかくインスタンスで環境を制限してるのだから、

適切に破壊してやった方がコードがスマートになると考えられるようになった。(11/06/02)

2週目:付箋はがしメモ

introduction.

xiii デザインパターンはリファクタリングの目標を提示する

xvi リファクタリング:コードの外のふるまいを変えずに内部の構造を改善してゆく

xviii

・並行性や分散性についての考慮はされていない <= 意味を取れず。

・オブジェクト指向がリファクタリングに役立つ

リファクタリングとは何かを知りたい時 => 第一章

リファクタリングがなぜ必要か => 第二章

どこをリファクタリングすべきかを知りたい時 => 第三章

実際にリファクタリングを行う場合 => 1-4を読む、カタログの脳内目次を作る、15章のゲスト執筆者の欄を読むのもお勧め

xix 危険なコードの匂い。いや臭い。

第一章 リファクタリング-最初の例

ビデオレンタルの管理システムのコード(java)。

初手でガシガシ書きすすめるようなプロトタイプではわりとありがちな気がする。

p7 テストを作る

リファクタリングではコードをいじるので、

いじる前にテストを最初に書く。

今回は不幸中の幸い?にもstatementが処理を掌握して、

文字列を返すようにしてあるので、

Customerクラスのインスタンスを作成して

if Customer#statement()=="判定文字列":
  print OK

とのようなコードを作ればいい。

p8 自己診断機能とは? =>テストの構築は具体的に第4章を参照せよ。

名前は大事。

vimであれば部分置換コマンド、Eclipseでは変数名の置換を行えばいい。

visualモードで選択後、s/oldwords/newwords/gと入力。

コマンドとしては

'<,'>s/old/new/g

となっていればいい。


Jythonからclassをテストしようとしたなら、

Movie.java以外はうまく読み込めなかった。なんでだろ。

p35 switch文のポリモフィズムへの置き換え

p49 思いつきで書いたんだろうけど、「AS3のリファクタリングはどうすんの」というメモが。

p50 導入したStateパターンについての再検討

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

原則をメモる。

リファクタリングとは:

外部から見たときの振る舞いを保ちつつ、

理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること

リファクタリングとコードのチューニングは、

同じコードをいじる作業ではあるが、

到達点が異なる。

チューニングは速度を、リファクタリングはソースコードの構造を、

よりよくする目的を持つ。

p55銀のやっとこ

リファクタリングを行うとコードが整理され・・・

・開発速度が加速する可能性を持つ。

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

・バグが見えやすくなる

  • 偉大なプログラマ--偉大な習慣を身につけたプログラマ

p57

リファクタリングは日常の作業の中に組み込むべき。

その1:三度目の法則でリファクタリング

最初は単純に作業をする。

2回目は気づいてもとにかく作業を続ける

3回目はリファクタリングを決行する

その2:機能追加の時にリファクタリング

その3:バグフィックスの時にリファクタリング

バグフィックス--バグ修正

その4:コードレビューの時にリファクタリングを行う

p60

リファクタリングのタイムロスに関して、

どう上司に説得するべきかの項(とばしました)


p63 データベースがリファクタリング時に問題となる。

ビジネスアプリケーションはデータベーススキーマに強く依存。

オブジェクトモデルとデータベースモデルとの間に分離のための層を設ける(ORM?)

アクセサを変更するだけでよく、バグを防ぎやすい。

p64 インタフェース(関数名など)の変更について

元のオブジェくトを完全にラップして、新たに作ってしまうべき。

JavaのCollectionクラスが良い例。

インタフェースを開示しすぎるな、スムーズなリファクタリングのためにはコードの所有権のポリシーを変えることも必要。


(次の文の意味をなんとなくしか取ることができない。

実際にはラップ時にどういうエラー文がでるのか?)

Javaにはインタフェースの変更に関して固有の問題があります。
throw節で投げる例外を追加する場合です。シグニチャの変更ということにはならないので、
委譲をつかってインタフェースの変更を吸収させる手は使えません。
対処法として、新たなメソッドには別の名前をつけて、古いメソッドは内部でそれを呼び、
発生する例外をRuntimeExceptionのサブクラスの例外として変換して、
コンパイルチェックが行われないようにします。

サブクラスで例外を再送するってことでいいのかな…。いや、もっと細かい意味があるような気も。

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

「設計が支配的」とは?


フルスクラッチ(全部書き換える)の方が早い場合はリファクタリングをしない。

プロトタイピングのコードはまちがってもリファクタリングで再利用なぞしない。

リファクタリングするにはコードが正しく動くことが保証されていなければいけない。


リファクタリングにはプログラムの設計を補完する役割があり、

はじめにきっちりとした設計をしなければ、もう終わりだ!というプレッシャーを緩和させる。

(だがしかし、設計をしないでやるのも無防備すぎるが。)

p67エクストリームプログラミング

CRCカードとは?

p69

リファクタリングによってパフォーマンスが落ちる恐れもある。

早いソフトウェアを作る3つの方法

1、時間分割を行うやり方

時間とメモリ使用量の観点から設計を細かなコンポーネントに分割する。

2、パフォーマンスを常に意識しておく

開発全体においてパフォーマンスを高めるよう意識をしておく

3、局所的な部分に意識を置く

パフォーマンスチューニングに局所的に処理が思い部分を改善する。

3番の方法では、

プログラムがリファクタリングされていると、

よりチューニングがしやすくなる。


code_smell