リファクタリング「本」のススメ vol.1

はじめに

全世界のみなさま、こんにちはこんばんは矢田です。

こちらはクリエーションラインアドベントカレンダー17日目の記事です。

普段はAgile CoEというチームで、製造業向けのデータレイク構築やアジャイル開発の支援を行っている合間で、社内の開発者（特に若手メンバー）に向けて技術1on1という枠組みでユニットテストやオブジェクト指向を教えています。

今回は若手メンバーと話をしている中で、「リファクタリング」という単語の定義について社内でも結構ふわふわしているなあと感じていたので、自分が理解している「リファクタリング」の定義について書いていきたいと思います。

このブログを通して社内の開発者の中でリファクタリング本を読み始める人が増えることを目的としています。また、「リファクタリング」の定義について軽い共通認識を持ってもらえたらものすごく嬉しいです。時間がない方は、第1章だけでも読む価値はあるのでぜひとも読んでほしいです！

「リファクタリング」の定義

現代のアプリケーション開発では非常に一般的な言葉だと思いますが、この記事を読んでいるみなさんは「リファクタリング」という言葉の定義を聞かれた時にどう答えますか？

社内でも「コードをより良くするための作業」というくらいの認識でしか捉えていないメンバーもいて、よくよく話を聞いてみると以下のようなことを話していたりしています。

とある若手開発者A

「変数名を変えたり、ファイルを関数やクラス毎に切り出す作業がリファクタリングだと思ってました」

とある若手開発者B

「常にリファクタリングをしていくというマインドセット的な感じかなあ」

もちろんそういうところも重要で間違ってはいるわけではないのですが、今回紹介するリファクタリングという本では、言葉の定義について以下のように書かれています。

名詞として、

外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変化させること

リファクタリング第2版

動詞として、

一連のリファクタリングを適用して、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること。

リファクタリング第2版

これは、あくまでも自分の解釈ではありますが、「リファクタリング」という作業の意図は、ソフトウェアに対して小さなステップを積み重ねて変更していくことで大きな変化をもたらすことであるにあると思います。

リファクタリング本から学べること

本の構成としては、

前半（1-4章）：リファクタリングについて体系的な説明

後半（6-12章）：安全に効率よくリファクタリングするための方法カタログ

となっており、この本を読み終えたときにコードにバグを加えずにソフトウェアの内部構造を変更できるようになります。（と書いてあります）

自分もこの本を読み進めていくことで、コードを変更するときの意識がかなり変わってコードを小さく変更させて内部構造を変えていく感覚が身についたように思っています。

本当はよくある読書ブログ的な感じで、全章それぞれに所感を書きつらねていきたいところなのですが、執筆時間の都合上簡単な具体例を挙げるだけに留めます。

と思ったのですが、アドカレのリリース日に全く間に合わないので、コードも省略します！第2回を出すのでそのときまでお楽しみに！

最後に

ということで、簡単にですが「リファクタリング」とリファクタリング「本」について紹介させていただきました！こういった記事を書いてはいますが、自分自身も道半ばなので、マサカリも大歓迎ですし、情報交換していける人が社内外で増えていけるといいなとか思っていたりします。そして、来年はオブジェクト指向とか、ドメイン駆動設計とかもっと範囲を広げて学習していきたい！（勉強することが多い…）

というわけで、明日は同じAgileCoEからいづみさんの記事をお楽しみに！（17日目のアドベントカレンダーと言いつつ、リリースが遅れたのですでに公開されています）