自己紹介

8月からLandit株式会社にて開発インターンをやっている大学4年生です。
実務経験はほとんどなく、別のインターンでVueを使ったプロダクト開発を1ヶ月ほど行っていたのみです。

記事を書こうと思ったきっかけ

社員の方にコードレビューをしていただき、たくさんのコメントを貰いました。「どうしたら他の人も読みやすいコードになるか」と考えていたとき、1本の動画に出会いました。
その動画では、「リーダブルコード」という本を紹介されており図書館で読んでみた所、「読みやすいコード・良いコード」を書くためのテクニックが書かれていました。
実際に、実践してみたところ感覚6割ぐらいレビューコメントが減り、「入社当初よりコードが読みやすくなった」と声をいただきました！
今回は、リーダブルコードを読んで実践して最も効果がでたこと、2ヶ月の開発でコードを読んでもらうという点で実践してよかったこと5選を紹介します。

1. コードリーディングをしてコード文化を知ろう！

チーム開発の中で、コードを揃えるというのは大切な事です。
1人1人コードの書き方が著しく違えば、可読性が低くなりバグの温床となります。
未経験の場合、特に自分なりにコードがかけたので自分なりに書きがちですがチーム開発の場合、一貫性があることが大切です。コードに一貫性を持たせる事で、可読性・保守性・作業効率が高まり追加実装やバグ修正の際に無駄な時間が削減できます。
できるだけ、実務に入る前にソースコードをいただける場合はコードリーディングを行いコード文化を知り、コーディング規約や命名規則がないか確認しておくと良いです！
もちろん、レビューでたくさんの指摘されるのが悪いという事ではありません。ですが、なるべくレビュー者の負担を減らすため、自身の精神的負荷を高めないためにも、予めコード文化を知っておくことはプラスになると思います！

私のエピソードとしてこんな事がありました。
JavaScriptで非同期通信をする時にawait/catchとthen/catchどっちを使うかという問題があります。
個人開発では、then / catchを主に使っていたのでthen / catchで書いていたのですが、レビューをいただいた時にawaitとcatchで使い分けている事を知りました。
予め、コードリーディングしておけば防げた事ですね、、、

そんな事にならないよう私は他のメンバーのプルリクにもできるだけ目を通すようになりました！

2. 命名は長くてもいいからわかりやすく！

これは、会社やチームによって違うかもしれません最近はCSSなども省略形を使わないというのがスタンダードだと思います。

<h1 class="ttl"></h1> titleの事かな？
<p class="msg"></> messageの事かな？

可読性が低いコードですね。

あなただけが読むコードであれば省略形で問題ないですが、チーム開発では自分以外の人がコードを読みます。転職ポートフォリオの場合は、企業のエンジニアがコードを読みます。

とにかく 「読み手」 の事を考えてコードを書きましょう！
こんな事にならないよう、長くなっても良いので意味が伝わる命名を行いましょう。

初学者でよくある例として、TODOアプリをイメージしてください。

❌ どんな値が入っているかイメージできない
const list
const item

⭕ 複数形だからTODOの配列だとイメージできる
const todos
const todo_list

関数内にスコープが閉じている場合は抽象的な命名でも良いですが、スコープに応じて適切な命名をしていると良いです。
命名で困ったら私はこちらのサイトを参考にするようにしています。

3. 変数や関数・ファイルは読みやすいように分ける！

初学者の場合、1つの関数に長々とコードを書いてしまいがちだと思います。
特にRailsやLaravelなどスクールで学んでいる方はコントローラー内に長々と書いてしまいます。（私もそうでした、、、）
初学時は、コードに慣れる事が大切なので最初は大丈夫です！ですが、実務では悪いコードです。
これは、関数・変数だけではなくReact・Vueでコンポーネントを作成する時も同じ事が言えます。

例）TODOに特定のリアクションが含まれているか確認し、持っている時はTODO名の配列をtodoTitles変数に入れる

❌ 悪いコード
const todoTitles = todos.map((todo) => {
	if(!todo.reaction.filter((reaction) => reaction.name === 'check').lenght > 0) return;
  return todo.title;
})

⭕ 読みやすいコード
const todoTitles = todos.map((todo) => {
	const hasTargetReaction = todo.reaction.filter((reaction) => reaction.name === 'check').lenght > 0;
	if(!hasTargetReaction) return;
	return todo.title;
})

悪いコードは、if分の条件に複雑な処理が含まれておりコードを読んだだけでは何をやっているのかさっぱりです。
逆に、読みやすいコードは複雑な処理を変数に入れ変数命名もどんな値が入っているかわかりやすくなったので読みやすいコードとなりました。

このようなに複雑な式を入れた変数のことを 説明変数 や 要約変数 などと言ったりします。

4. タイポは未然に防ごう！

コードを書いていく中で、タイプミスはよくあるかと思います。
特に、英語が苦手な方はよくあるかと思います。（私もそうです、、、）
タイポにより予期せぬバグの発生やコードを検索した際にも見つけることが難しくなります。ですが、これらを差し置いてめちゃくちゃ恥ずかしいです、、、
そんな私でもスペルミスを劇的に減らす事ができる神プラグインを教えていただきました。
私の場合、VScodeをよく使用するのでVScode限定になってしまいますが「Code Spell Checker」というプラグインを使う事でスペルミスはほとんどなくなります。

画像のようにタイポしている場合は青い波々でタイポしている所を教えてくれます。

また、「Code Spell Checker」と付随して紹介したいのが「Error Lens」です。
Error Lensは、VScodeの静的解析で見つけたエラーをエディタ上に表示してくれるので、開発者が瞬時にエラーやワーニング・タイポに気づくことができます。

これでほとんどのスペルミスは検知できます！
あとは、意図しない値を入力してしまった時のタイポを防いであげましょう。

例えば、フィルタボタンの実装をイメージしてみましょう。

<FilterButton
  isSelected={"all" === selectedStatus}
  onClick={() => onClickFilterStatus("all")}
  label="すべて"
/>

このコードの場合、”all”という文字列がisSelectedとonClickに記載されています。
この場合、2つのことが考えられます。

“all”という文字列が複数箇所記述されている事でallから別の文字列（”valid”など）に変更になった際に全箇所を修正する必要がある
“all”以外の文字を記述した時にバグが発生する

この可能性を防ぐために“all” という文字列を定数で定義しておくてことで文字列が変更になった時に1箇所変更するだけで済み、意図しない値が入る事も防ぐ事ができます。

const ALL = "all";

<FilterButton
  isSelected={ALL === selectedStatus}
  onClick={() => onClickFilterStatus(ALL)}
  label="すべて"
/>

5. コードレビューを依頼する前に自分でレビューしよう！

これは、私が最近意識するようにしていることです。
やはり実務が初めてとなると、レビュー時にご指摘をたくさんいただくことがあります。ですが、その指摘が何度も同じような指摘だとレビュー側の負担にもなりますし、自分への負担にもなります。
どうにか自分で解決できないかと考えた結果、プルリク前に自分でコードをレビューをすれば良いと気づきました！
GitHubだとプルリク作成時にマージ先との差分が表示されるので、そのタイミングで一通り目を通して

不要な変数・コメントアウトを残していないか
変数名・関数名は分かりやすく・誤解されない命名になっているか
変数や関数・ファイルが適切に分けられているか

この3つの点を意識しながら確認をしています。

ポイントは、新鮮な目で見ることです！！

私の場合、集中してコーディングし終わったとき「これで良い」という錯覚に陥るため、細かなミスを見逃しがちです。コーディングが完了したら一息ついて、新鮮な目にして自己レビューをするように意識しています。
これをするだけでだいぶ細かいミスを減らす事もでき、リファクタ力も向上していると感じました！

まとめ

5選紹介してきましたがいかがでしょうか？

5つ以上に細かく知っておいてほしい事は多りますが、この5つを知っておけば現場に入っていち早く開発業務に慣れることができるかと思うのでまずは自身のポートフォリオなどで実践してみてください。

「キレイなコードを書く・良いコードを書く」にはどうしたら良いか悩んでいる方や、さらに興味を持った駆け出しエンジニアの方は、冒頭で登場した「リーダブルコード」という本を是非購入して読んでいただけたらと思います。

駆け出しエンジニア必読書です！！