コードを書く時の重複回避に向き合う

処理が動いてからが本番〜重複回避のためにやっていること

こんにちは。まいむです。

少し前のブログでコードの重複回避ができず苦戦したことを書きました。

その後のフィヨルドブートキャンプの課題でも重複を見落としていることが度々あって、DRYなコードを書くって難しいな〜と思って今も課題と向き合う日々です。

いつもレビューをしてくださるメンターさんとペアプロをする機会があって、相談したところ

「処理が動いてからが本番。そこからコードを読み直して自分でレビューをすることがまずやれること」

とアドバイスをいただきました。

それ以来「動いた！！やった〜！！！」ではなく、頭を切り替えてはじめからコードを読み直して処理を見直していく時間をより大切にするようになりました。

そこで、今回は重複回避のためにやったこと実践していることを書きたいと思います。

こちらの本もメンターさんに教えていただいて、Rubyのプラクティスの中盤あたりで一気読みしました。

読んだからといって重複なく書ける訳ではないのですが・・・何を気をつけるべきかというフックを自分の中に持つきっかけになりました。

Railsのプラクティスが終わった頃に読むと受け取り方がまた変わっているだろうなという実感があるため、定期的に読み返したいなと思います。

いわゆるリファクタリングなのですが、私はここに時間をかけることが足りず今は意識的にまとまった時間を当ててコードを処理の流れに沿って読み直しています。最近あったのはファイルの更新処理をルーティングのメソッドごとに個別に書いていて、これは共通化できるなと後から気がついたことがありました。

File.open(file_name, 'w') do |file|
      JSON.dump({変更内容を入れた変数}, file)
end

これを今回はクラス内でクラスメソッドとして定義して、ファイルに更新をかけたい時に引数を渡して呼び出せるようにしてみました。

ここでいつも難しいなと思うのは答えは必ず1個ではないということ。

（コナン君みたいに「真実はいつもひとつ！！」と言えたら良いのにw）

そこで実践しているのがリファレンスを読むことです。

フィヨルドブートキャンプのメンターをされているチェリー本筆者の伊藤さんにもDRYなコードを書くためにはどうしたら良いかをペアプロしていただいた際に聞いてみました。

（私は割と課題に思っていることはいろんな方の意見を聞いて片っ端から試すタイプですw）

その際にアドバイスいただいたのが

「リファレンス読んでる？」

でした。自信満々に読んでます！と返事をしたのですが、本当にただ読んでいるだけでしたw

今は読み方を変えて、リファレンスに記載されているサンプルコードと自分のコードを比較して直せる点はないかという観点でリファクタリングの際に活用しています。

ここでもリファレンスをちゃんと読んでよかったな〜と思ったことがあるのですが、

以下はRubyリファレンスに記載されているsprintf のコードサンプルです。

case ENV['LC_TIME']
when /^ja_JP/
  fmt = "%1$d年%2$d月%3$d日"
else
  fmt = "%2$02d/%03$2d/%1$02d"
end

p sprintf(fmt, 1, 4, 22) #=> "04/22/01"

こちらは引数は変わらず出力するフォーマットを条件に応じて変える例として記載がされていました。

私はこの逆で、引数は変わるけど出力するフォーマットは共通という処理に対して、それぞれメソッド定義をして2回同じ処理を書いていました。

リファレンスのサンプルと完全に同じではないものの考え方のヒントが載っていて、無事に処理を1個にまとめることができました。

ただ、リファレンスも読むタイミングがあると思っていて、コードを書く前と後で読むと受け取り方が変わると思います。

どうやって実装するか考えている段階ではリファレンスを読み込むのが苦痛だったりしますw

ある程度処理が通って、自分がやりたいことが明確になったタイミングで読み直す時が一番役立っている実感があります。

こんな感じで今日はコードの重複回避とどうやって向き合っているかを書いてみました。私はまだまだ学んでいる過程のため、ここに書いたことが変わっていく可能性が十分ありますが、その場合は同じテーマで改めてブログを書きたいと思います。

では、また〜！