Javaのより良い書き方を指南する『Java言語で学ぶリファクタリング入門』（1/2）

結城浩『Java言語で学ぶリファクタリング入門』を写経しつつ読んでいます。

本書は全部で15章あり、大きく3つの内容に分かれています。

そのうち、本エントリーでは「コードを整える小規模なリファクタリング」「クラスを整える中規模なリファクタリング」を説明した第10章までを扱います。

「クラスの関係を整える大規模なリファクタリング」を説明した第11章～第15章は別エントリーに回します。

対象読者

サンプルコードの処理内容はそれほど難しくないと思います。2つ目の条件の理由ですが、本書を有効活用するには、実際にコードを書くことが不可欠なためです。

本書を読んでいるとリファクタリングが行われる理由や背景は二つあるように思います。

未熟なプログラマーが書いたコードはそもそも修正の余地があります。

一方で、「最初から全部正しく」コードを書けていてもリファクタリングは必要です。第5章で

プログラムというものは作られた後、たくさんの修正を受けるものです。

とあり、それらの修正に合わせて、リファクタリングは必要になっていきます。

取り上げられている章のいくつかは、リファクタリング前のコードが明らかにイケてないものがあります。

先ほど挙げた背景のうち「未熟なプログラマー」の方です。

例えば、第1章はマジックナンバーの是正を扱っているのですが、これについては初めからマジックナンバーを含まないようにコーディングしていれば、そもそもリファクタリングが必要なくなります。

特に以下の章は、このように「そもそもどんな時でも修正前のような書き方はしないだろう」という印象を受けました。

多かれ少なかれ、全部の章にあてはまるのかもしれません。例えば、いくつかの章で見られる、以下のようなタイプを示すコードです。

    public static final int TYPECODE_LINE = 0;
    public static final int TYPECODE_RECTANGLE = 1;
    public static final int TYPECODE_OVAL = 2;

上の3行は図形のタイプを示しているのですが、Enumを使うし、数値は使わなさそうです。

このように、本書にはJavaのより良い書き方を指南しているという側面があります。

一方で、修正や機能追加が進んだ結果、ifやswitchが増えてしまったので、それを整理していく、といった行為は、「度重なるプログラムの修正」で必要になったリファクタリングでしょう。

ここで、本書に立ち戻ってリファクタリングの定義を確認すると、

外部から見たプログラムの振る舞いを変えずに、プログラム内部の構造を改善すること

とあります。つまり、プログラムの改善理由は何でもいいわけで、本書が単純な*1「Javaのより良い書き方とは」という内容になっていても全く問題ないという考えに至りました。

話は変わりますが、本書ではサンプルコードも用意されていますし、リファクタリングの手順も丁寧に記載されています。

実際に手を動かしてリファクタリングすることがとても重要です。

本を見ながらやってできるようにならなければ、実際のコーディングでリファクタリングができるようにならない、と思うからです。

ここ最近、自分がJavaを書く上で教わったことや気づいたことがかなり載っていて、その点はうれしかったです。

繰り返しになりますが、分かっているだけではダメで、実際に書けることが重要だと思います。本書は良い練習台になると思います。

*1:主観を多分に含む