こんにちは。リブセンスでエンジニアをしているfkm_yです。
もし2年前にWeb業界へ入ったばかりの自分へコードを書くときのアドバイスをするとしたら…要領の悪い私へ最低限これくらいは指摘受ける前に出来ててほしいなと思うことを書いてみました。
メソッドの役割は１つにしよう
例えば1つのメソッド内で作成と削除など複数の役割を与えると複雑になってしまいます。複雑になってしまうと変更がしにくく、再利用もしにくいコードとなってしまいます。また何の役割のメソッドなのか定義するのも難しくなってしまいます。
変数やメソッドには正しい名前を付けよう
極端ですがupdate_xxxと書いてあるのに削除されているととても読みにくいです。名前の通りの処理になっていれば読みやすく、機能の拡張やバグ修正がとてもしやすいです。
YAGNIを意識しよう
YAGNIは"You ain't gonna need it"の略で「必要になってから作る」的な意味です。
よくシステムを作っている将来的にはこういう機能も必要になるかもしれないと推測で機能を作ろうとすることがありますが、そもそも使われない可能性もありますしコードの複雑度が上がってしまいます。必要になるかもと推測で作る機能よりも今必要な機能のクオリティを上げるようにしましょう。
N+1問題に気をつけよう
N+1問題とは1(親テーブル)+N(子テーブル)件のクエリが発行されてしまい、パフォーマンスを著しく落としてしまう問題です。クエリの発行回数を抑えるには事前にデータをロードしておけば対応することも出来ます。
慣れるまでは発行されるクエリのlogを視て確認するか、bulletgemを使ってN+1を検知するようにしましょう。
例外を意識しよう
接続エラーやnullなどの不正な値が送られてくるケースを考慮しよう。
コードを書いてる時には正しいデータを想定しがちだけど、思いの外おかしなデータが渡されてきます。
その際におかしな挙動をさせないためにも例外処理を書いて場合によってはシステムを止めるようにしよう。不正な値でシステムを正常終了させて不正な結果を返しても良いことはありません。
また例外発生時のメッセージは具体的に書き、エラー発見者がアクションできる情報を書きましょう。「例外が発生しました」だけとかは本当に止めましょう。原因調査、影響調査に時間が掛かってしまいます。
公式ドキュメントを読もう
ついついその場しのぎのハウツー記事を読んでしまいがちですが、公式ドキュメントを読みましょう。ハウツー系の記事は情報が古いなどで正しくない可能性もあります。必死になって探していた情報が公式情報に記載されていたなんてこともあるので公式ドキュメントを読むようにしましょう。