コードレビューでよく指摘される理解しているつもりなのになかなかできないこと

フロントエンドエンジニアとしてのキャリアをスタートさせて6か月が経ちました。そこで、これまでに私が先輩エンジニアたちからコードレビューを通してよくご指摘いただいたことを備忘も兼ねて記事にしてみることにしました。もしよかったら読んでみてください。

関数の役割（責務）

• 作りたい機能を実現するために必死になって実装していると、ついひとつの関数に複数の役割を持たせてしまっていました。複数の役割を持つ関数を作ってしまうと、"ちょっと違う同じような機能を持つ関数" が溢れかえったり、読み返したときに理解しづらいコードになってしまったりします。関数の役割はなるべくひとつに、シンプルイズベストを心がけたいです。
• はじめのうちはすぐにコーディングに着手するのではなく、日本語に落とし込んでみてからコーディングすると整理できます。私の場合はコメントで日本語に落とし込むようにしています。

エラー・注意文

• エディタやブラウザのコンソールなどにエラーや注意文が表示されていても、とりあえず動いているからとほったらかしにしてしまうことがありました。エラーや注意文が出ているということは何か問題があるよと親切に教えてくれているので、それに対してまずは気になるようにしていきたいです。
• エラーや注意文は英語の記載が多いためか、ないがしろにしてしまうことも多いのではないでしょうか。そこで翻訳ツールを利用するのもひとつの方法です。私は DeepL というサービスを使っています。インストールしておけばショートカットで手間いらずなことと、翻訳精度も高いのでおすすめです。

命名規則

• そのときの雰囲気で決めた変数名や関数名はあとで見返すと、何を意味しているのかよくわからないことが何度もありました。それだけではなく、値（変数・定数）なのか処理（関数）なのかさえわからないこともありました。命名した本人ですらわからないのですから、他の人が見てもわかるはずもありません。わかりやすい命名を行うことで少しでも可読性の高いコードを書けるようにしていきたいです。
• まずは自分の悪いクセを知ることから始めるのもやり方のひとつだと思います。私の場合は命名した変数名・関数名を一覧化して見返すことで自分の命名の悪いクセを見つけるようにしました。他にも、評判の良いライブラリのコードを読んでみたり、先輩エンジニアの書いたコードを読んでみたりすると勉強になります。また、codic というプログラマのためのネーミングツールもあるので興味のある人は見てみてください。

マジックナンバー

• コーディング中に "えいや" と書いてしまっていたのがこのマジックナンバーです。マジックナンバーとは、

「この数字の意味はわからないが、とにかくプログラムは正しく動く。まるで魔法の数字だ」という皮肉を含む。 (Wikipedia より)

という意味だそうです。上述の命名規則と同様、わかりづらいコードの一要因となりますので、なるべくマジックナンバーを書かないように心がけたいです。

• まずは敵（マジックナンバーによる悪影響）を知り、そして己（自分のクセ）を知ることで対策を打ちましょう。例として、私の場合はとりあえず動くものを作らないとと焦っているとついやってしまいます。コーディング中は主観的になってしまいやすいので、定期的に自分の書いたコードを見返すようにしています。

最後に

• 実際にコードを書いてみると、理解しているつもりでもできていないことはよくあります。一度見てわかったつもりでコーディングをしても、結局体現できないまま同じことを繰り返してしまいます。何度も意識して取り組むことで徐々に自分のものになると思うので、上に書いた 4 つのキーワードを何度も目に焼き付けて体得したいと思います。