Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
俺たちはなぜコードレビューをするのか
Search
Daichi Koike
March 29, 2024
Technology
200
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
俺たちはなぜコードレビューをするのか
Daichi Koike
March 29, 2024
More Decks by Daichi Koike
See All by Daichi Koike
OpenAPI 3.0でmicroserviceのAPI定義を試みてハマった話
daichike
0
33
カヤックの組織課題を解決する人事データベースシステム
daichike
0
25
DP4版と侮るなかれ!現時点でもN1QLは実用に耐えうる/Couchbase Live Tokyo 2015
daichike
0
16
Couchbase Serverのサーバ移管と2.1から3.0.1へのバージョンアップ
daichike
0
16
Couchbase Serverを用いた大規模データ収集基盤/db tech showcase 東京 2014
daichike
0
25
Other Decks in Technology
See All in Technology
子育てエンジニアの可処分時間が減っても成長を諦めない戦い方
sudoakiy
6
4.6k
スプシの手作業からの解脱 ~更新はClaude Codeに、見せ方と使い方はGASアプリに任せる~
kentarofujii
0
150
ソフトウェア ファクトリー - 再現性のあるソフトウェアの工場づくり / Software factory
iktakahiro
6
4.9k
『SAR衛星データ解析入門』のご紹介とその応用
syuchimu
0
120
ブラウザとサーバーから考えるAI時代のフロントエンド監視
shogo4131
3
940
事業成長とデータ活用を止めないためのマネジメントへ挑戦
hiracky16
0
390
Benchmarking Disaggregated Serving on vLLM + Dynamo with a Real Coding-Agent Workload
nttcom
1
190
Tofu-Controller lightning talk @ Containerday 2026
gionn
0
110
Gemini Intelligence 入門 ― AppFunctions と Gemini Nano
takuroabe
0
250
実体験から学ぶ分析エージェントの開発と運⽤
recruitengineers
PRO
8
2.4k
エンタメ企業のM&Aを支えるデータ基盤 ― 統合から店舗のリアルタイム分析まで / Data Engineering Summit 2026
genda
0
170
分析の民主化を支えるメタデータ整備の実践
kakehashi
PRO
4
1.4k
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
So, you think you're a good person
axbom
PRO
2
2.2k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.5k
Believing is Seeing
oripsolob
1
240
Reflections from 52 weeks, 52 projects
jeffersonlam
356
22k
Test your architecture with Archunit
thirion
2
2.4k
First, design no harm
axbom
PRO
2
1.3k
We Have a Design System, Now What?
morganepeng
55
8.4k
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
500
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
68
59k
Mobile First: as difficult as doing things right
swwweet
225
10k
Transcript
俺たちはなぜコード レビューをするのか 2024-03-29 小池 大地 【KURAND社 協賛】仕事とお酒を愛でる「ソース コード」レビューまつり!
こんにちは - 小池 大地 - 面白法人カヤック 人事/サーバサイドエンジニア Go で Web
app を書いたり Terraform で AWS のインフラ構築したり - 好きなお酒 麦焼酎
レビューしてますか?
https://chat.openai.com/share/f1758a92-6088-48a2-bf4a-42c359b42fc5 コードレビューの目的(GPT-4)
コードレビュー(英: code review)は、ソフトウェア開発工程で見過ごされた 誤りを検出・修正することを目的としてソースコードの体系的な検査(査読)を 行う作業のこと。 https://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC コードレビューの目的(Wikipedia)
まあわかる でもレビューじゃなくても 良いものもない?
- レビュアーがどれだけ真剣にレビューしても全部のバグを発見はできない - 実装が妥当かどうかはユースケース(どのように使われるか)によって決定さ れるので、コードだけ見ても分からない場合が多い 例: 名前を入力するフォームのバリデーション ひらがな/カタカナ - 実装者もレビュアーも全員ドメイン知識に精通しているとは限らない
- Pull Request マージ後の E2E の動作確認や QA でもバグを検出することが できる 品質(バグ)
学習と成長 - モブプロやペアプロといった手段がある - レビューは成果物に対して行うので思考や実装の過程は分からないが、モブ プロやペアプロであればこの過程を体験できる。特に初学者のメンバーに対 してはこちらのほうが良いと感じる - ちょっとしたリファクタリングや管理画面の改修などをお題にして行うと ちょうどよい。終了後はそのままマージすることも可能
レビューの目的とされてい るものは代替手段があるこ とが多い
ではなぜレビューするのか
https://chat.openai.com/share/f1758a92-6088-48a2-bf4a-42c359b42fc5 コードレビューの目的(GPT-4)
保守するから
- 実装者以外のチームメンバーがそのコードをメンテナンスできることを合意 するため - 2~3年も運用すればビジネスの要求が変化していき、初期のアーキテクチャ や機能では想定していない改修が発生する - ビジネスの要求と、ビジネスを継続していく中で変化していく要求にアプリ ケーションが応えられなければならない。この状態を維持することが人間に よるレビューの目的
なぜレビューするのか
- 設計 - アーキテクチャ、モジュール、レイヤ、関数など - 設計を誤ると後続の実装がすべてつらくなる - 良い設計になっていれば実装が誤っていても後から修正しやすいし、要求の 変化にも対応しやすい -
設計を終えたビルドや CI が通らない状態で一旦レビューをすることもあ る。実装まで終えた状態だと設計に見直しが入った場合に大きな手戻りが発 生し逆に工数がかさむことがある。大きな実装の際に有効 何をレビューするのか
保守しない前提ならレ ビューは必ずしも必要では ないのでは?
- 短期のキャンペーンサイトの開発など、保守運用を前提としていない開発 - もちろんレビューできるならレビューしたほうがいいが工数は無限にあるわ けではない。感覚的には実装工数が2時間ぐらいのものは30分近くレビュー に必要。負担になるとレビューが雑になり、レビューすることが目的となり がち - シンプルなエンティティの CRUD
操作のような振る舞いが明確で後の工程で 不具合として検出しやすいもの - 管理画面など、システムの信頼性の低下をある程度許容できるもの レビューを省略できる可能性があるもの
レビューしてますか?
- バグになりうるコードを検出する linter - go vet と staticcheck https://staticcheck.dev/ -
linter と統合して動き自動レビューをする reviewdog 🐶 https://github.com/reviewdog/reviewdog - credentials のリポジトリへのコミットを防ぐ git-secrets https://github.com/awslabs/git-secrets ツール
酒とゲームとインフラとGCP 『ゲームインフラ』をキーワードに お酒を飲みながら Google の技術を楽しむ 次回 7/5 (金) SQUARE ENIXさん会場
https://sake-game.connpass.com/event/312225/
ありがとうございました