Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
プルリクを分割して レビュー負荷を軽減する
Slide 2
Slide 2 text
自己紹介 エンジニア3年目 趣味：サウナ、ボードゲーム ぎゅう（@gyu_outputs） → 前職:Laravel / Vue / AWS → Golangを現在メイン → エンジニア仲間と行きます
Slide 3
Slide 3 text
技術本を友達と書いてます
Slide 4
Slide 4 text
レビューが大変という 経験はございませんか？
Slide 5
Slide 5 text
変 更 フ ァ イ ル 数 多 い な ぁ よ し 、 あ と で 見 る か ぁ 分割でレビューが必要になる
Slide 6
Slide 6 text
前どこまで確認したっけ？ ファイル数が多いと起こりがち...。
Slide 7
Slide 7 text
ま だ レ ビ ュ ー 中 だ か ら 、 も う 少 し 待 っ て ね レビューが後回しにされることも
Slide 8
Slide 8 text
一気にマージされて、コンフリクトに苦しむ コ ン フ リ ク ト 多 す ぎ こ れ 全 部 修 正 は 大 変 だ っ て
Slide 9
Slide 9 text
そんな現場に役立つ方法
Slide 10
Slide 10 text
プルリクを分割して レビュー負荷を軽減する
Slide 11
Slide 11 text
プルリク分割が注目されている
Slide 12
Slide 12 text
現職でもかなり分割されている そ う い え ば 当 た り 前 で は な い の か ？ こ の 会 社 の リ リ ー ス 回 数 多 く て 驚 き ま し た ※ フ リ ー ラ ン ス
Slide 13
Slide 13 text
変更行が500行は多すぎです プルリク分割してください 自分も過去に注意をされる
Slide 14
Slide 14 text
でも、どう分割すれば？
Slide 15
Slide 15 text
そんな話をします
Slide 16
Slide 16 text
プルリクの分割単位
Slide 17
Slide 17 text
findyの資料を見てみましょう
Slide 18
Slide 18 text
※findyより
Slide 19
Slide 19 text
補足説明を入れると、
Slide 20
Slide 20 text
※findyの画像に補足説明を追加 テーブル作成 モデル作成 Repository作成 usecase作成 handler作成
Slide 21
Slide 21 text
利用していないから、リリースしても問題なし テーブル作成 モデル作成 Repository作成 usecase作成 handler作成 リリースしても影響なし QA実施
Slide 22
Slide 22 text
テーブルを作成 model, Entityを作成 handlerを空で作成。swaggerを記述してAppチームに共有 必要であれば検証用に仮データをreturn Repositoryの実装 Usecaseの実装 handlerの中身を実装 フロントエンドとAPIの繋ぎ込み→ 動作確認 → QA実施 関数が必要になったら、こまめにプルリク発行 1. 2. 3. a. 4. 5. 6. 7. 8. プルリク分割の単位
Slide 23
Slide 23 text
完 全 に 理 解 し た
Slide 24
Slide 24 text
モ デ ル に 関 数 追 加 し た し 、 テ ス ト 書 い て プ ル リ ク あ げ よ
Slide 25
Slide 25 text
LGTM 2分ほどでプルリクを確認できる
Slide 26
Slide 26 text
レビュー時間を圧倒的に短縮
Slide 27
Slide 27 text
メリットはそれだけではない
Slide 28
Slide 28 text
メリット① コンフリクトの負荷軽減
Slide 29
Slide 29 text
handler usecase Repository handler usecase Repository API API コンフリクト コンフリクト コンフリクト マージ 機能が一つ増えると、コンフリクトの影響範囲が大 一気に修正は大変
Slide 30
Slide 30 text
API handler usecase Repository API handler usecase Repository コンフリクト コンフリクト コンフリクト コンフリクトが分割されることで、負担が軽減される
Slide 31
Slide 31 text
コンフリクトのストレス軽減
Slide 32
Slide 32 text
マイクロサービスアーキテクチャ などを活用しなくても 問題なく開発が進められる
Slide 33
Slide 33 text
メリット② タスク管理がしやすい
Slide 34
Slide 34 text
handler usecase Repository: Get TODO TODO DOING Repository: Save TODO タスクが細分化されて、状況がわかりやすい 早くしないと...。
Slide 35
Slide 35 text
handler usecase Repository: Get DOING DOING DOING Repository: Save DOING フォローしやすい 手伝いますね 手伝いますね 手伝いますね ありがとうございます
Slide 36
Slide 36 text
状況に合わせて 柔軟に対応できる
Slide 37
Slide 37 text
予定より早くリリースできました 競合他社よりも早くリリースできる
Slide 38
Slide 38 text
モブプロで設計を決める
Slide 39
Slide 39 text
このコード何？ってなるのでは？
Slide 40
Slide 40 text
モブプロで実装方針を整理する Notionで実装方針の認識を合わせる
Slide 41
Slide 41 text
あの箇所の プルリクですね
Slide 42
Slide 42 text
実装方針の認識が一緒なら 問題なし
Slide 43
Slide 43 text
Githubでなるべ く管理したい モブプロの最適解は模索中
Slide 44
Slide 44 text
最後に、、、
Slide 45
Slide 45 text
負担が軽減することで 毎日2~5回リリースも可能
Slide 46
Slide 46 text
あなたの会社でも プルリクを分割しては？
Slide 47
Slide 47 text
ご清聴ありがとうございました