こんにちは、製品企画室ニュービジネスグループの松永です。
今回はリファクタリングのお話です。
前回までに書籍管理アプリの開発を行い、一通りの機能が完成しました。
これだけ見ると「お、なんか動くものできてんじゃーん」と思う方もいるかもしれませんが、中身のコードには触れていませんでした。
如何せん実務未経験の新卒が作成したアプリケーションです。
可読性は最悪と言って良いでしょう。
それを改善するために、今回は実務開発でも使われている静的解析ツールを導入してリファクタリングを行いました。いくつか使用しましたが、本日取り上げるのはrubocopと呼ばれるgemです。
（gemはRubygemsと呼ばれるパッケージ管理システムで利用可能な外部ライブラリを指します。他言語で言えばpipとかnpmでインストールしたライブラリのことを指している感じです。）
さて、早速使ってみましょう。コマンドラインから実行します。
とりあえず設定はデフォルトのままにしましょう。
よーしリファクタリングするぞー
…
…
…
うわっ・・・私の可読性、低すぎ・・・？
所見ですとかなり面食らいますが、個別のメッセージをざっと見てみると大半は
「(文字列内で式展開しないなら)ダブルクォートのかわりにシングルクォートを使うのが好ましい」とか
「コンマの後は半角スペースをきちんと開けた方が良い」
といったものでした。
こうした単純な校正に関しては、”rubocop -a”で解析を実行すれば自動で修正してくれる機能があります。便利ですね。
また、文字コードの懸念からか「コメントを英語で書け」等の無茶振りも多くみられました。TOPSICの規約ではダブルクォートの使用が許されていますし、日本語のコメントも許可されているため、それにならっていくつかコンフィグを設定し、rubocop側に許してもらいます。
また、本アプリではRSpecと呼ばれるテストフレームワークを使用してテストも実装しているのですが、テストコードには別の規約を適用する予定であるため、今回はコンフィグ設定でフォルダを対象外とします。
自動修正やコンフィグ設定を経て、73件が残りました。
さらにメッセージを見てみると、binやnode_modules等の解析が不要であろうフォルダも引っかかっていましたので、こちらもコンフィグから設定して解析対象から外していきます。
最終的にはコントローラーやモデルなどに関係する、要するに自分で書いたコードに関する指摘が20件程残りました（スクショ撮り忘れ）。
私の場合、「メソッドの行数が長すぎる」「メソッド名はスネークケースにしろ(Javaの影響からキャメルケースで書いていました)」「循環的複雑度が高い」などの項目が残っていました。
これらを修正していきます。
指摘が徐々に減っていく感覚はぷちぷちを潰すのに似た楽しさがありました。
全て修正が終わったところで、晴れてリファクタリング完了となります。
趣味でプログラミングをしていた頃は可読性をあまり気にしていませんでしたが、指摘されてみると納得するものも多く、非常に参考になりました。
今後実務開発で他の人のコードを見る機会が増えることで、可読性の大切さをより実感できるのだと思います。
本日はリファクタリングのお話でした。
これを機に普段から心がけたいと思います。
