# レビューの観点を整理してみよう2021夏 外注先に依頼する際には、コードレビューを工程に含める目的として 1.要件適合性確認（修正コスト低減のため） 2.仕様把握（技術的負債低減のため） と明示していますが、 もう一回チーム内での認識をあわせるため 以下、みなさんが感じることを教えてほしいです！ ## コードレビューのメリット - 中身を把握することで、更新時の事前調査時間が少なくて済む - 中身を把握することで、更新時の予定工数が見積もりやすい（見積精度があがる） - 中身を把握することで、どこかに変更を加えようとするときの影響範囲がわかる - 作業者ひとりでは、見落としがちな問題を見つけることができる - ブラウザチェックでは気づけない作りの問題に気づくことができる - 品質の担保につながる - 制作会社のスキルレベルを見分ける目安になる - 他人のコードを読むことによって学びや発見を得ることができる 👉 6/11 MTGを踏まえそれぞれ、コードレビュー自体はよい取り組みとして捉えていることがわかった。 ## 😵‍💫今抱えている問題点 - ひとによって見る観点が違う - 時間がかかる 👉吹越案：案件によってやる・やらない、どこまで見るのか？やる狙いを考え、メリットがあるものについては、かけるべきコストとして対応。 - うちのフローに則ってコードレビューに対応してもらうための事前のすりあわせや説明会などの手間が発生 - 手間をかけた成果が得られないことがある - レビュアーが少ない - コードレビュアーが見る？ ディレクターが見る？責任分界点が曖昧 ## レビューするときにセットで考えてみるといいよ、ってこと（レビュアーが持つべき目） - 実現可能な範囲か？ - 指摘を反映することで、どんなメリットが生まれるのか？ - 環境を整えることで改善できること（別課題として意見を上げてほしいな） - 指摘する内容は、事前に伝達している内容か？（GTMのidや、TD、OGPなどが未挿入でも事前に伝達されていないことがあるため指摘前に確認が必要） 😵‍💫 フロントにたつ進行担当者とコードレビュアーとの情報格差がある状態。 - レビュー担当者が変わった場合や、複数人でレビューする際にはどうやって擦り合わせるか？ 蓄積されたノウハウ、ナレッジをどこに貯めるか？ 😵‍💫 中身を把握することで得られるメリットが、属人的してしまっている状態。 - タグの使い方がセマンティック（タグの意味を正確な解釈で）に使われているか - レビューするにあたり、視認性の高いコードか（例：入れ子が入っているか） 👉 [レビューの観点](#レビューの観点)に含める。 ## レビューされる側が思うこと - どれくらいの期間でレビューの戻しがくるのか - PR発行コメントに何を書けばよいのか？ 😵‍💫 課題として整備したほうが良さそう。 --- 次に… ## レビューの観点 を洗い出してみたいです。 案はこちら、「コーダーレビュー」の章です。 https://chibineko.jp/t/p3s361KO5x6qQAIq3OFRfg --- ## 別課題化すべきケース - コード整理 -