「DIVE INTO CODE」学習記録 #24
こんにちは。
24日目。リファクタリング。可読性を意識する。
学習内容
【リファクタリング】
- きれいなコードと汚いコード
- fat controllerとは
- scopeの利用
- fat modelとは
- concernの利用
- バリデーションの切り出し
- コールバックの切り出し
- service objectの利用
- fat viewとは
- 異なるcontrollerに紐づくviewファイルのパーシャルの利用
- パーシャルでの変数の取り扱い
- ヘルパーの利用
- ActiveSupportについて
- ActiveSupportの便利なメソッド（squish、truncate、sum、blank?、present?）
- エスケープシーケンス
- any?メソッド
- nil?メソッド
- empty?メソッド
- presenceメソッドとpresent?メソッドの違い
- in?メソッド
- GitHubのフォーク機能でのクローン作成
- リファクタリング実践
感想
今回はリファクタリング実践。
リファクタリングとは、「汚いコードをきれいなコードに書き直すこと。」
もっと丁寧な説明にすると、
「アプリのふるまいは維持し、第三者でもコードの理解や修正が容易になるよう内部構造を改善すること。」
まずどのようなコードが汚いコード認定を受けるのか。
逆にどのようなコードがエンジニアを「おっ！」っと思わせるのか。
リファクタリングとは、アプリケーション共同開発における可読性及びデバックのしやすさを維持するために必要なこと。
であるとともに、他のエンジニアに
「こいつわかってるな。」
という評価を受けるエンジニアとしての評価指標の面を伺わせる、
何とも上級者な分野だと思う。
そもそも汚いコードすら書くのが危うい僕のようなレベルが、
この「上級者のアソビ」に首をつっこむのは早かったのかもしれない。
嘘です。リファクタリングに「上級者のアソビ」キャラつけて遊んでました。
実際現場でどんなもんかはまるで知りません。
とりあえず初心者ながら感じたことはリファクタリングは修正処理を行う際に効果を発揮する。
早い段階から意識して取り組んで損はないなと。
可読性の面は現段階では一人で開発できる規模感のものしか考えてないので、そこまで必要性はないかもしれないですが。
まあ余裕あればやっていきます。
リファクタリングには色々なルールがあります。ルールを統一することが必要みたいです。
個人で見やすいだけでは本来の可読性を高めるという意義に反します。
大規模開発ではコードの書き方を統一させるためのマニュアルを作ってから、
それに則ってコード書いてくれ、ってやってくそうです。
正直リファクタリングすると習ったコードがどんどん切り出され、
違うファイルに移され、紐付けのコード書いて・・・
これ前の方がわかりやすくない？
ってなる状況です。今は。
フォルダの場所も複数ですし、
切り出すたびに知らないコード書かされます。
モデルとビューとコントローラーでそれぞれ違います。
concern、validator、callback、service object、helper・・・・
非常に初心者に優しくない設計づくりです。
初心者に対する可読性は下がる一方です。
リファクタリングのルールの具体例としては、
viewファイルでは後置if使った方がいいよ、
とかあります。
理由としては、行数が減り可読性が上がることと、
viewファイルにRubyはできる限りコーディングしない方がいいというルールがあるため。
ex )
<% if logged_in? %>
〜略〜
<% else %>
〜略〜
<% end %>
こういうのをviewからとにかく減らした方がいいという話。
今回の場合、減らすためには、各行の後ろに行数分の後置ifを書きます。
コーディングする文字数的には後置ifした方が増えますが、
可読性の面では向上するみたいです。
細かい部分を詰める作業工程なのでどこまで意識でいるかわからないですが、
今後はできるだけ使ってみようと思います。
以上ありがとうございました。