リファクタリングとは

先だって公開した記事でも述べた通り、私はその場の思いつきでアプリを作成してきたので、自分のコードを見直してこなかった。

機能を追加するために見直すことはあったが本当の意味で「見直す」ではなく「過去の自分（他人）が書いたコードの意味を再解釈する」という無駄な行為だったように思う。

今まで自分が実装してきた機能をどのようにして実装したのかを振り返るためにもコードの見直しを行いたいと思う。

どうやらエンジニアの中では「リファクタリング」という行為があるらしい。

早速調べてまとめてみる。

まずはきれいなコードから

そもそもきれいなコードとは何か。

読みやすくて、修正しやすいコードである。

他人（過去の自分）がみてもすぐにどんな処理をしようとしているか理解できるコードのことではないだろうか。

コードが難解だと時間というリソースを消費するし、不具合の温床にもなる。

ではきれいなコードの条件とは何か。

・同じ処理はまとめる

同じ処理が繰り返し書かれていると、コードが読みづらく修正時に修正箇所が多くなってしまう。

ロジックに変更が生じた場合に、多くの既存コードを修正することになり、その分修正漏れが生じる可能性が高くなる。

ミスを減らすにはコードを書かない方が良い（※有名著リーダブルコードより）のでまとまった処理はメソッドとして抽出し、処理部で呼び出す方が良い。

・ネストは浅くする

if文などでネストが複雑に組み合わさっているとネストが深くなって、条件が理解しづらくなってしまう。

修正時の閉じ括弧や閉じタグの漏れにも繋がる。

必要であればメソッド化するなどして、読みやすい条件にするべきである。

変数名・関数名をわかりやすくする

名前だけでどんな変数or関数なのか想像できるようなネーミングにすること。

名前で役割や処理がわからないような名前は、その後の処理もわかりづらくしてしまう可能性がある。

リファクタリングとは

読みづらいコード、わかりづらいコードをきれいなコードに修正すること。

機能の追加やバグ修正をするわけではなく、内部的な機能は変えずに、理解や修正が簡単になるようにコードのみを修正する。

タイミングは開発中に見直した時でも、時間をとって見直した時でも良いが、もっとわかりやすく短く書けないか（短くてもわかりづらくては意味がない）を考えながら、問題のありそうな箇所を見つけ、わかりやすいコードに変更する。

実際にリファクタリングしてみた

直近で開発していたPHPアプリケーションで実際にリファクタリングを行ってみた。

以下はデータベースのcategoriesというテーブルの行数と、categoriesテーブル内のidとnameカラムの内容をコレクションとしてそれぞれ変数へ代入するという処理である。

-        $numrecord = DB::table('categories')->count();
-        $categories = DB::table('categories')->pluck('id', 'name');
+        $cat_record_count = DB::table('categories')->count();
+        $cat_id_name = DB::table('categories')->pluck('id', 'name');

git log の出力であるため、行頭の"-"が変更前、"+"が変更後である。

変更前はnumrecord、categoriesといった抽象的で、変数の中身を推測しづらい名前だったため、処理のわかりやすさという点を意識して変数名を変更した。

まだまだ筆者のセンス不足を感じる点もあると思うが、変更前よりはわかりやすくなった。

他のコードも含めてまだまだ改善の余地があると思うので今後もリファクタリングは気付いた時に随時行って、未来の自分が見て即時に理解できるコードを書くようにしていきたい。