【Ruby on Rails】リファクタリングに対する誤解
はじめに
先日リリースいたしました、初学者でも技術記事を手軽に投稿できるようにするアプリMiniitaのリファクタリングに取り組んでいます。
これから本格的に取り組むにあたり、改めてリファクタリングに関して学んだことがあったので今回の記事を書いております。
参考になりましたら幸いです。
リファクタリングに関する誤解
今回改めてリファクタリングに関して理解を深めるために、下記の動画を視聴しました。
1つ目の動画では、リファクタリングに関する誤解が3つ紹介されていました。
そのうちの1つで、外部の振る舞いを保証するために、リファクタリングを行う前に必ずテストコードを書くこととお話しがありました。
現在Rspecでモデルスペックは一通りかけましたが、システムスペックがまだ終わっていないため、リファクタリング前に早急にシステムスペックを書き上げなければ...と焦っています。
本格的にリファクタリングする前に、この動画を視聴してよかったです。
また、汚いコードから手当たり次第リファクタリングすることも非推奨とのことでした...。
現在リファクタリングをしていきたいと考えている箇所は下記です。（1つ目はリファクタリング済み）
-
マイページの遷移先（プロフィール編集、自分の投稿記事など）を、usersコントローラー内で独自アクションとして定義するのを辞める。
-> こちらの記事を参照に、独自アクションを設定しているものを新たなコントローラーのindexアクションとして切り分けました。
この記事を読む前まではコントローラー数が増えることに少し抵抗感がありましたが、第三者から見た時のわかりにくいと感じ独自アクションとして定義するのをやめました。 -
OpenAIのAPIを使用している箇所を、コントローラーからサービスオブジェクトへ移動する。
-> 今回OpenAIのAPIを記事の投稿・編集箇所と、マイページ内継続サポート機能で使用しております。それぞれのコントローラー内で実装しておりますが、これを1つにまとめるべくサービスオブジェクトへ移動させたいと思っています。
サービスオブジェクトを使用することにより処理を共通化し、fatコントローラー解消に努めたいと思います。ここに関してはまだ理解が浅いため、学習をしてからリファクタリングに取り掛かります。 -
モデルの整理
-> Articleモデルが現在100行に渡って処理が実装されています...。投稿へのいいねメソッド、通知機能のメソッドで肥大化している状況です。コメントは追記しているものの可読性は低いので、どうにか整理しなければと考えています。
2つ目の動画の中では、悪いコードが生まれてしまう理由は「その場しのぎ」でコードを書いているからという話がありました。
まさに上記コードはその場しのぎで書いてしまっている部分があるので、改善していきたいと思います。そのためにもなにはともあれテストコードを書き上げて、リファクタリングに取り組みます。
最後までご覧いただきありがとうございました。
Discussion