16
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

爆速成長とチーム幸福を実現!新卒2年目エンジニアが実践するPRを読む・書く技術

Posted at

はじめに

開発を行う中で、PRを読んだり書いたりする機会がたくさんあると思います。
PRの読み方や書き方によって、自分の成長に繋げられたり、レビュワーを幸せにできると思ったので、自分なりに工夫しているポイントを本記事で共有します!

PRを読む技術

PRを読むタイミングは大きく2つあるかと思います。

他メンバーのPRをレビューする時

他メンバーのPRをレビューすることは、コードの品質向上だけでなく、自分自身のスキルアップにも繋がる重要な機会です。学習の場としても活用することで、レビュー力と実装力の両方を向上させることができます。

自分の開発タスクに関連する実装の背景,周辺知識をキャッチアップする時

新しいタスクに着手する前に関連するPRを読むことで、過去の設計判断や実装の背景を理解し、より良い実装方針を立てることができます。闇雲にコードを書き始めるのではなくて、事前の調査に時間をかけることで、開発効率と品質の向上に繋げることができます。

それぞれの工夫について記述します。


他メンバーのPRをレビューする時

先輩方と一緒にレビューする

私が所属しているチームでは1対1でのレビューも行いますが、昼会等のタイミングでモブレビューを行うことがあります。モブレビューで先輩と一緒にレビューをすると以下の点が良かったです。

レビュワーの視点が身に付く

モブレビューでは以下のようなやり取りがよくあります。

先輩A: 「ここの部分他の実装方法考えてみた?」
先輩B: 「自分だったらこう書くんですけどどうですか?」
先輩C: 「今回の実装に関連する箇所のここの処理ってどうなってるの?」

最初の方はこのモブレビューの中で自分はどういった点を確認,指摘をすれば良いかわからなかったのですが、だんだんとレビューを重ねるうちに、レビューの観点や、PRを読む時に時間をかけるべき場所かどうかがわかるようになりました。
これにより、一人でレビューする際にも先輩の視点を意識してチェックできるようになります。


自分の開発タスクに関連する実装の背景,周辺知識をキャッチアップする時

タスク着手前に関連するPRをザーっと眺めて集める

関連するPRを見ることで、設計に役立てたり、よりよい実装方法を見つけることができます。実際にコードを読む前に把握しておくことで、物語のあらすじを読むような感覚でスムーズにコードリーディングに移ることができます。
以下の基準で読むことを意識しています。

どのPRを見るか

PRの種類 確認する理由
機能自体が実装された最初のPR 機能自体の目的や、初期実装での考えを汲み取る
直前のPR リファクタリングや、不具合修正が行われている場合が多いので、直近どんなことが課題だったかを読み取る

どの観点を見るか

  • ディスカッション内容
    • 特に実装方針,設計において議論されているものがないか確認する
  • 変更されたファイルの種類や範囲

実装方針を考える中で、複数の実装方法で迷った場合、これらを参照すると既に活発に議論されていることがあり、納得できる結論や背景がわかるので、自分の実装に役立てることができます。


PRを書く技術

PRを書く際に工夫できるポイントは大きく2つあります。それぞれについての工夫について記述します。

レビュワーの負担を減らすためにできること

レビュワーにとって理解しやすいPRを作成することは、レビューの質を高め、開発チーム全体の生産性向上に貢献することができます。レビュワーが迷ったり悩んだりする時間を減らすことで、より本質的な議論や改善提案に時間を使ってもらうことができます。

自身の理解を深めるためにできること

PRを作成する過程は、自分の実装を振り返り、設計判断を言語化する貴重な機会です。レビュワーとの議論を通じて新たな視点を得ることで、単なるタスク完了以上の学びを得ることができ、今後の開発力向上に繋げることができます。


レビュワーの負担を減らすためにできること

既存のコードの理解に時間がかかった場所と自身の実装で時間がかかった場所にはコメントを書く

PRの説明文やコードコメントで、理解に時間がかかった箇所を明記することで、レビュワーがスムーズに理解できるようになります。自分が実装する際に調査した既存の仕様と実装についての内容や関連するPRや、文献を載せると良いと思います。

セルフレビューを行う

PR作成後、他人のコードをレビューする気持ちで自分でもう一度確認することで、誤字脱字や論理エラー等のより良い実装に気づくことができ、レビューのラリー回数を減らすことができます。

セルフレビューのチェック観点

自分は以下の観点でチェックすることが多いです。

  • 新たに作成したファイルのディレクトリ構成や、変数名が適切かどうか
    • ディレクトリ構成や、変数名はタイポなどをしていない限りエラーにならないためです。
  • 直近の自分のレビューや他メンバーのレビューであった指摘と同じような記述をしていないか
    • これらの指摘はいわゆる「やってしまいがちな指摘」なので矯正するためにも時間をかけて確認した方が良いです。

自身の理解を深めるためにできること

複数の実装パターンが思いついた時には、コメントで残しレビューで意思決定のFBをもらう

タスクを行う中で選ばなかった実装の選択肢もあると思います。大小関わらず、迷った実装方法をPRのコメントで明記することで、レビュワーから設計判断の根拠や、より良いアプローチについてアドバイスをもらうことができます。

コメントに残すと良い内容

例えば以下のような形でコメントに残すと、有意義な議論に繋がりやすいです

  • 検討した実装方法とそれぞれのメリット・デメリット
  • 最終的に選んだ理由
  • 判断に迷った点や不安な箇所

これを行うことで自分では気づかなかった観点を学ぶことができたり、他のタスクを行う際の意思決定に転用できる知識にしたりすることができます。


おわりに

本記事では、PRを読む技術と書く技術について、私が新卒2年目として実践している工夫をまとめました。これらの取り組みを通じて、レビューの質が向上し、自分自身の成長にも繋がっていることを実感しています。

特にモブレビュー事前のPR調査は、一人では気づけない視点を得られる貴重な機会です。皆さんもチームの文化や環境に合わせて、これらの工夫を取り入れてみてください。

最後まで読んでいただき、ありがとうございました!🙏

16
8
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
16
8

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?