
ついつい仕事で作ったプログラムのリファクタリングは後回しになりがちで、作業が一段落しても、なかなかモチベーションが上がらないのが、コードの改善作業です。
そうしたリファクタリングを、理論的に、その後の改修効率を向上させるべく、書籍でわかりやすく解説されている書籍です。
仕事でプログラミングをして、他の人のコードを改善することがある場合に、この書籍を読んでおく必要があるぐらいいい書籍でした。
評価
★★★★☆
とにかく、実際のコードをもとに、より良くリファクタリングする手順が順番に書かれています。
これまでめんどくさい作業としか思わなかったリファクタリングが、パズルを解くかのような感覚になってきて、むしろ面白さすら感じさせてくれる内容でした。
自分が過去に書いたコードを軒並みリファクタリングしたくなりましたね。
また、リファクタリングをこなしていくうちに、自分が初期構築するプログラムに関しても、書き方のルールのようなものが、GoFのデザインパターンを基準にして、
より効率のいい書き方が最初からできるような成長も感じられます。
こうした経験の繰り返しで、人はプログラムスキルが向上していくんでしょうね。
この書籍で学べるポイント
いつリファクタリングを行うべきか?
リファクタリングは、「定期的に行う」のが効果的です。
効率的に行うためには、自動テストも必須ですね。
逆にリファクタリングをするべきではないタイミングは、以下の通りです。
・1回しか実行せずに削除する予定のコード
・廃止が決まっていて、現在はメンテナンスのみ行なっているコード
・パフォーマンスが優先される開発
リファクタリングパターンの鉄則
・メソッドは5行以内に抑える。
・if~elseは使わない。
・if文は、メソッドの冒頭のみにとどめる。
・switchは使わない。
これらのルールを元にリファクタリング・パターンを覚えていくことで、効率的なコードに作り変えることができる。
複数のif文をまとめる
if ~ if elseで、"body" が同じであれば、||でまとめる。
※bodyというのは、if文の中の処理です。
interfaceで管理する
classオブジェクトを使ったリファクタリングが多く書かれていて、データや情報の整理のためにinterfaceを使います。
class内のプロパティを統一化するルール作りで必要なんですね。
ifをclassに移行する
この書籍でこだわっているのは、if文を極力使わないという事でした。
if文は使わないけど、三項演算を使って、boolean判定を行なって、それぞれのclassで処理することで、
class名やプロパティ名を適切に書けば、コメントなども不要になるという、プログラミングの根底ルール的な内容です。
複雑な条件文をまとめる
||と&&は、とにかくプログラミングを複雑にしがちなので、それらをどのようにすればスッキリとまとめられるかという内容は、通常のプログラミングの精度も上がる内容なので、必須で覚えておきたい内容ですね。
コメントを削除する
とにかくコメントはあまり良いものではないというのが、こうしたコーディングルール的な書籍にはよく書かれています。
この本では、コメントはリファクタリングした際に、陳腐化することも多いので、そういうものは残さず削除することが勧められています。
また、コメントには別パターンもあり、古いコードを残しておく、いわゆる処理を一時的に伏せている状態もあります。(自分もよくやります)
git管理しているのであれば、こうした伏せコードコメントは消した方が絶対に良いとのことです。
ただし、「不変条件が書かれた」コメントは、残すようにしましょう。
リファクタリングのルールまとめ
この書籍における鉄則ルールは以下のとおりです。
# 1メソッドを5行までにする
- 基礎となるデータ構造を扱うのに必要な最低行数にとどめる。
# 関数は、呼び出すか渡すかにする
- オブジェクトメソッドを呼び出すか、引数としてオブジェクトを渡すかのどちらかで、混同しないこと。
# メソッド内でif文は、最初だけにする
- メソッド内で、複数のif文を書かないほうが良い。
# if文のelseは使わない
- ただし、制御できないデータ型をチェックする時を除く。
# switchは使わない
- ただし、defaultが無い全てのcaseでretuenを返す場合を除く。
# 継承はinterfaceからのみにする
- クラスや抽象クラスではなく、interfaceだけからにする。
# 純粋な条件式を使用する
- 条件式は、変数に値を代入したり、例外を投げたり、入出力処理を行なったりしない。
# 実装が1つしかないinterfaceは作らない
- 実装クラスが1つしかないインターフェイスは、作らなくてもいい。
# ゲッター、セッターは使わない
- ブール値以外の値を直接代入したり、戻すメソッドを作ってはならない。
# 共通の接頭辞、接尾辞を持たせない
- 複数箇所から呼び出されるクラスに特定の接頭辞や接尾辞を持たせると、意味の違う処理になる可能性がある。
あとがき
普段書いているプログラミングを根底から否定されるかのようなコーディングルールにびっくりする人もいるかもしれませんが、そもそもの説明を聞くとなかなかの納得感がある。
もちろん、ルールはあくまでルールであって、コーディングにおける例外などもたくさん存在するので、そうした時にどのようにするのがいいかという経験をたくさん積んでいくことがスキルアップの道になります。
お作法としてのリファクタリングを学ぶのにこの書籍は非常にいい学びになりましたね。
初心者の人には、書いてあるコードなどが難しく感じるかもしれませんが、こういう技術書は書いてあるコードを実際に自分で書いて確認することも学習手法の一つでもあります。
ちなみに、本書籍のコードは、githubにアップされているので、それをなぞって読み進めることができるので、パソコンを片手に読むスタイルになっていました。
0 件のコメント:
コメントを投稿