はじめに

最近、綺麗なコード（自分の中では変更しやすいコードという意味）とは、どのようなコードなのかということが分からなくなっていました。

また、コードレビューの中で「これは自分の好みを押し付けているだけではないだろうか」と感じることがありました。
どこまでが一般的に言われる保守しやすいコードなのか、どこまでが自分の好みなのかという線引きが分からなくなってきていました。

そのため「綺麗なコード（保守しやすいコード）とはどのようなコードなのか」を再確認するために、ここ2ヶ月ほど集中的に勉強していました。

そこで、同じような悩みを持っている方の参考になればと思い、どのようなことを勉強していたのかをまとめました。

勉強していたこと

そもそも、オブジェクト指向に則って考えられないと適切なクラス設計はできないと考えて『オブジェクト指向設計実践ガイド』を再読しました。

本書は過去3回ほど読んだのですが、その時は理解できていなかった部分が多かったです。
今回は写経しながら読み進めたこともあり、ようやく「依存 = 変更する際の摩擦」であることを実感を伴って理解できました。

それにより「クラスが他のクラスの情報を知りすぎている（つまり依存度合いが大きい）」という状態を検知でき始めてきました。

今までは臭うコードを見ても「どこが良くないのか、どのようにすれば良くなるのか」を言語化できていませんでした。

そこで、リファクタリングについて学びたいと思い『リファクタリング Ruby エディション』を読みました。

本書では「どのようなコードが臭うコードなのか。そのような臭うコードには、このリファクタリングの手段が使える」といった、リファクタリングのレシピが明確に示されており大変勉強になりました。

本書を読んだことで、リファクタリングをより言語化して考えやすくなった感覚があります。

望ましいとされるスタイルルールを知るために「Ruby Style Guide」を読みました。

Rubocop のデフォルトに従っていれば、このスタイルを逸脱することはないですが、そもそもどのようなルールに従っているのかを把握するために読んでみました。

「自分の好みを押し付けているかも知れない」と感じていた部分が Style Guide には明記されていました。
そのため、「自分の好みの書き方なのか、共通認識を得られている書き方なのか」の線引きができ始めてきました。

良いコードの引き出しを増やすために以下の3点に取り組みました。

問題への解決方法がパターン化されているものは、それを学んだ方が早いと思い『Ruby によるデザインパターン』を読みました。

「あのコードは、このパターンを使っていたんだ」ということが発見できて面白かったです。
また、パターンを知ってることで問題に直面した時、解決方法までの道のりをショートカットできそうだと思いました。

メソッドを知っていれば、綺麗に書けたという場面が数えきれないくらいあるので Ruby リファレンスマニュアルの「組み込みライブラリ」まで一通り読みました。

Enumerable#partition など知らなかったけれども、役立つメソッドを知ることができてよかったです。

Sinatra を読んで、今は Sorcery を読んでいる最中です。

Sinatra の throw catch を使った処理の抜け方や、Sorcery の Adapter の考え方など勉強になりました。
まだまだ読んだコードの絶対量が足りないので引き続き読んでいきたい所存です。

上記のようなことをインプットしたからといって、すぐ綺麗なコードを書けるわけではないとは思っています。
特に自分の場合はコードを書いた量・読んだ量がまだまだ足りないので、インプットしたことをコードに反映して試行錯誤していくことが必要なのだと感じました。