フロントエンドエンジニアとして配属されて約半年が経ちました。
実装タスクを担当するようになり、レビュー依頼をする機会が増えてきました。
コードレビューは、エンジニアの成長に非常に重要なプロセスだと考えています。
レビューを受ける側は、自分の書いたコードについてフィードバックを受けることで学び、改善することができます。また、レビューをする側も他の人のコードを読み、異なるアプローチや解決方法を学ぶことができます。
今回は、自分がコードレビューを出す前に指摘されたことと、その改善案をまとめます。
前提
自分が担当しているプロジェクトでは、GitHubを使っていて、フロントエンドを担当しています。
使用しているエディタはVSCodeです。
主に、保守、新規機能実装を行なっています。
指摘①：実装による他への影響
既存のコードを変更することで、他の部分に思わぬ影響が出ることがあります
コードレビューがなければ、間違った修正が反映されるところでした。
対策：コードリーディングを徹底する
変更する前に、影響が出そうな部分を洗い出し、確認することを心がけています。
影響のありそうなファイルを全て確認する必要があるため、時間はかかりますが、後戻りする方が時間も手間もかかります。
もし実装で不明点があれば、早めに質問した方が、労力も時間も短縮できます。
過去のPRを参考にすることでわかることもあります。
vscodeのgitlensを使うと過去のコミットを探ることができます。
一にコードリーディング、二に質問です。
指摘②：コメントで補足する
コードの変更に対してコメントを付けることが重要です。
なぜ変更したかを記載することで、レビューアーの負担を減らすことができます。
対策：コードを変更しながらメモする
レビュー前に、メモした内容をコメントとしてコードに記載するようにしています。
変更が必要だと思った理由と、行った変更点をメモしながらコードを書くように心がけています。
メモすることはかなり重要で、コメントする内容に直結します。
メモ中に間違いに気づくこともあります。
コードの変更を言葉でまとめることで、理由づけされている正しいコードを書けるようになります。
指摘③：コメントアウトを適切に
不要なコメントアウトや誤解を招くコメントアウトは避けるようにします。
実装者を逆に混乱させてしまうことになります。
対策：リーダブルコードを読む
変数や関数名だけで意味が伝わるコードを書ければ、コメントを書く必要はなくなり、コードが簡潔になります。
特殊な処理を書いている場合は、実装時の状況を詳しくコメントとして残します。
また、事前に説明が必要そうな場合にも、コメントを残すようにしています。
指摘④：変数名、関数名を正しく
変数名や関数名に意味を持たせることで、より伝わりやすい実装ができます。
また、コメントアウトを減らすことで、ファイルがすっきりと整理されます。
対策：リーダブルコードを読む
以下の記事が非常に勉強になりました。
「なんとなく」ではなく、しっかりと説明できる命名が重要です。
指摘⑤：規則性を探す
コード規約に沿ったコーディングを意識することが必要です。
動くだけでは不十分で、規則性のある書き方や命名が求められます。
対策：コードを読む
コード規約がしっかりと定められているプロジェクトでは、コードを読むだけで規則性を簡単に見つけることができます。
間違った規則性は負債になってしまうため、正しい規則性を見つけることが重要です。
関係する全てのファイルを確認する気持ちで、何度もコードを読む必要があります。
コードを読むことで、実装のヒントを得られることもあります。
指摘⑥：簡潔に書ける
コードは簡潔で理解しやすいことを心がけるべきです。
既存のコードを活用し、共通化を意識することが重要です。
対策：過去のPRを漁る
過去問で対策するように、過去のPRを確認します。
レビューアーの視点を持つことで、良いコードを書く力が養われると思います。
指摘⑦：セルフレビューをする
PRを出す前に一度見直すことで、ミスに気づくことがあります。
とりあえずレビューを依頼するのではなく、完璧に近い状態で依頼するべきです。
対策：セルフレビューを徹底する
セルフレビューを徹底することが大切です。
過去の指摘に該当する部分がないか、再度確認する必要があります。
中途半端に依頼してしまうと、レビューに大きな工数がかかってしまいます。
まとめ
コードを読み、適切な命名をし、正しいコメントを残すことを意識するべきだと学びました。
コーディングにスピードは求められませんが、その代わりに理解に時間をかけることが求められます。
レビューでの気づきが、エンジニアとしての成長につながると感じています。
最後に
最初のうちは、レビューされることに抵抗を感じていましたが、最近ではコードレビューを必要なプロセスとして捉え、なるべく指摘をもらわないようにコードを書くことを意識しています。
レビューされることを意識してコードを書くことで、初めてレビューアーとしてコードの指摘ができるようになると思っています。