Tweet
Tweet

Slide 1

Slide 1 text

©MIXI ©MIXI MIXI 24新卒技術研修 Git研修 Advanced 2024/04/16 デジタルエンターテインメントオペレーションズ本部 モンスト開発部 モンストサーバ1グループ サーバチーム 飯島 緋理

Slide 2

Slide 2 text

2 ©MIXI 自己紹介 ➔ 飯島緋理 (いいじまあかり ) ➔ 富山県出身 ➔ 2022年新卒入社 ➔ モンストサーバチーム ◆ モンスト 運用と開発をしています ➔ コーヒー(浅煎り)が大好き ◆ 毎朝ハンドドリップしています ➔ 麻雀が好き ➔ ライブコーディング気になる

Slide 3

Slide 3 text

3 ©MIXI こ 講義 目的とゴール 目的 　どこでも通用するチーム開発 基礎を学ぶ ・Git を用いたチーム開発 ノウハウ ・GitHub を用いたチーム開発 ノウハウ ゴール 　『気遣い』ができるエンジニアになる

Slide 4

Slide 4 text

©MIXI Q. そもそもなぜ Git が⽣まれたのか

Slide 5

Slide 5 text

©MIXI Q. そもそもなぜ Git が⽣まれたのか A. チーム開発するため （Linux を開発するため）

Slide 6

Slide 6 text

6 ©MIXI Git 誕生秘話 1991〜2002年 Linux メーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料 VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux フリーソフトな に 　非フリーソフト BitKeeper を 　利用してよい でしょうか。」 Linux パパ Linus Torvalds 氏 「BitKeeper 使用に反対意見が 　あるなら代わり VCS を教えて 　ください。」 みんな 「...」 2005年 大人 事情で色々あって「 BitKeeper」が有料化されてしまった Linux パパ Linus Torvalds 氏 「他 VCS 探さないといけません。 　でも BitKeeper しか Linux を扱えません。 　もう VCS 自作します！」 Linux と Git パパ Linus Torvalds 氏 「2週間でできました！」 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 2005年〜現在 Git 多く プロジェクトで使用されている Git 「Linux 並に大きなソフトウェアを 　大人数で開発するために生まれました」 他にも 色々あったよ 詳しく Git 略史で 調べて

Slide 7

Slide 7 text

7 ©MIXI Git 誕生秘話 1991〜2002年 Linux メーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料 VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux フリーソフトな に 　非フリーソフト BitKeeper を 　利用してよい でしょうか。」 Linux パパ Linus Torvalds 氏 「BitKeeper 使用に反対意見が 　あるなら代わり VCS を教えて 　ください。」 みんな 「...」 2005年 大人 事情で色々あって「 BitKeeper」が有料化されてしまった Linux パパ Linus Torvalds 氏 「他 VCS 探さないといけません。 　でも BitKeeper しか Linux を扱えません。 　もう VCS 自作します！」 Linux と Git パパ Linus Torvalds 氏 「2週間でできました！」 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 2005年〜現在 Git 多く プロジェクトで使用されている Git 「Linux 並に大きなソフトウェアを 　大人数で開発するために生まれました」 他にも 色々あったよ 詳しく Git 略史で 調べて

Slide 8

Slide 8 text

8 ©MIXI Git 誕生秘話 1991〜2002年 Linux メーリスに投稿されたパッチを気合いで適用しながら開発 2002年 「BitKeeper」という有料 VCS を無料で使わせてもらえることになった フリーソフトウェア活動家 Richard Stallman 氏 「Linux フリーソフトな に 　非フリーソフト BitKeeper を 　利用してよい でしょうか。」 Linux パパ Linus Torvalds 氏 「BitKeeper 使用に反対意見が 　あるなら代わり VCS を教えて 　ください。」 みんな 「...」 2005年 大人 事情で色々あって「 BitKeeper」が有料化されてしまった Linux パパ Linus Torvalds 氏 「他 VCS 探さないといけません。 　でも BitKeeper しか Linux を扱えません。 　もう VCS 自作します！」 Linux と Git パパ Linus Torvalds 氏 「2週間でできました！」 参考：Quora “What are some well-written accounts of the Linux-Bitkeeper-Git story?” , Git 略史 , Wikipedia：BitKeeper Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License. 2005年〜現在 Git 多く プロジェクトで使用されている Git 「Linux 並に大きなソフトウェアを 　大人数で開発するために生まれました」 他にも 色々あったよ 詳しく Git 略史で 調べて

Slide 9

Slide 9 text

9 ©MIXI Git 特徴 Git 大きなソフトウェアを大人数で開発するためにある Git 以前 VCS に比べて Git に 次 特徴がある ● 高 な merge と checkout ● 分散型 ● branch

Slide 10

Slide 10 text

10 ©MIXI Git 特徴 Git 大きなソフトウェアを大人数で開発するためにある Git 以前 VCS に比べて Git に 次 特徴がある ● 高 な merge と checkout ● 分散型 ● branch Git merge と checkout かなり高 特に「履歴 遠さ」 merge や checkout 時間に影響を与えない ※ Basic Git 研修「Git 内部構 」で詳しく話しています

Slide 11

Slide 11 text

11 ©MIXI 分散バージョン管理システム (分散型) リポジトリ 全履歴を含めた 完全なコピーをローカルに持つ Git 特徴 Git 大きなソフトウェアを大人数で開発するためにある Git 以前 VCS に比べて Git に 次 特徴がある ● 高 な merge と checkout ● 分散型 ● branch 参考：バージョン管理に関して ローカル・バージョン管理システム ローカル み シンプルな VCS 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Local Computer Central VCS Server Computer A Computer B Server Computer A Computer B Version Database Version Database Version Database Version Database Version Database File File File File File Clone 同期 Clone 同期 メリット： 　単純で理解しやすく個人開発に適している デメリット： 　チーム開発に適してない メリット： 　チーム作業 管理と共有がしやすい デメリット： 　単一障害点になる＆変更 競合が起きうる メリット： 　障害に強い＆柔軟なチーム開発ができる デメリット： 　運用次第で非効率なチーム開発になる

Slide 12

Slide 12 text

12 ©MIXI 分散バージョン管理システム (分散型) リポジトリ 全履歴を含めた 完全なコピーをローカルに持つ Git 特徴 Git 大きなソフトウェアを大人数で開発するためにある Git 以前 VCS に比べて Git に 次 特徴がある ● 高 な merge と checkout ● 分散型 ● branch 参考：バージョン管理に関して ローカル・バージョン管理システム ローカル み シンプルな VCS 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Local Computer Central VCS Server Computer A Computer B Server Computer A Computer B Version Database Version Database Version Database Version Database Version Database File File File File File Clone 同期 Clone 同期 メリット： 　単純で理解しやすく個人開発に適している デメリット： 　チーム開発に適してない メリット： 　チーム作業 管理と共有がしやすい デメリット： 　単一障害点になる＆変更 競合が起きうる メリット： 　障害に強い＆柔軟なチーム開発ができる デメリット： 　運用次第で非効率なチーム開発になる

Slide 13

Slide 13 text

13 ©MIXI 分散バージョン管理システム (分散型) リポジトリ 全履歴を含めた 完全なコピーをローカルに持つ Git 特徴 Git 大きなソフトウェアを大人数で開発するためにある Git 以前 VCS に比べて Git に 次 特徴がある ● 高 な merge と checkout ● 分散型 ● branch 参考：バージョン管理に関して ローカル・バージョン管理システム ローカル み シンプルな VCS 集中バージョン管理システム (集中型) リポジトリを完全にサーバが管理する Local Computer Central VCS Server Computer A Computer B Server Computer A Computer B Version Database Version Database Version Database Version Database Version Database File File File File File Clone 同期 Clone 同期 メリット： 　単純で理解しやすく個人開発に適している デメリット： 　チーム開発に適してない メリット： 　チーム作業 管理と共有がしやすい デメリット： 　単一障害点になる＆変更 競合が起きうる メリット： 　障害に強い＆柔軟なチーム開発ができる デメリット： 　運用次第で非効率なチーム開発になる

Slide 14

Slide 14 text

14 ©MIXI Git 特徴 Git 大きなソフトウェアを大人数で開発するためにある Git 以前 VCS に比べて Git に 次 特徴がある ● 高 な merge と checkout ● 分散型 ● branch branch 機能 おかげで大人数で並行して開発を進めることができる ※ Basic Git 研修「ブランチ 使用」「Git 内部構 」で詳しく話しています しかし、無秩序な branch 運用に 問題点がある ● 様々な branch でコンフリクトが発生してしまう ○ 複雑なコンフリクト 解消に失敗してバグが混入する可能性がある ● ど branch にど 機能が実装されている かわからない ○ 最新版がどれかわからなくなってしまう 大規模なチーム開発を効率的に行うために、 branch 運用に いくつか 方法論がある！ 1番有名な が 『Git Flow』

Slide 15

Slide 15 text

15 ©MIXI Git 特徴 Git 大きなソフトウェアを大人数で開発するためにある Git 以前 VCS に比べて Git に 次 特徴がある ● 高 な merge と checkout ● 分散型 ● branch branch 機能 おかげで大人数で並行して開発を進めることができる ※ Basic Git 研修「ブランチ 使用」「Git 内部構 」で詳しく話しています しかし、無秩序な branch 運用に 問題点がある ● 様々な branch でコンフリクトが発生してしまう ○ 複雑なコンフリクト 解消に失敗してバグが混入する可能性がある ● ど branch にど 機能が実装されている かわからない ○ 最新版がどれかわからなくなってしまう 大規模なチーム開発を効率的に行うために、 branch 運用に いくつか 方法論がある！ 1番有名な が 『Git Flow』

Slide 16

Slide 16 text

16 ©MIXI Git Flow と ブランチ戦略 一つ。分散型だが、集中型。 → 集中型 「管理 しやすさ」を分散型に導入 → (必須)チームでリモートリポジトリ(GitHub, BitBucket, 　 GitLab, etc…)を1つに決めて常にそれを正とみなす → メイン branch： main, develop (無期限) → サポート branch：feature, release, hotfix (有期限) 参考：A successful Git branching model feature develop release hotfix main

Slide 17

Slide 17 text

17 ©MIXI Git Flow と 参考：A successful Git branching model feature develop release hotfix main 余談：複数リモートリポジトリ状態もあるよ 例1　GitHub ができる前から Git 使っている OSS 自前 Git サーバと GitHub を両方使っていたり する(git log 残すためとか) 例2　fork したリポジトリを、fork 元 リポジトリに 追従したい時に複数リポジトリを扱う場合がある 例3 もう片方 バックアップ用 ブランチ戦略 一つ。分散型だが、集中型。 → 集中型 「管理 しやすさ」を分散型に導入 → (必須)チームでリモートリポジトリ(GitHub, BitBucket, 　 GitLab, etc…)を1つに決めて常にそれを正とみなす → メイン branch： main, develop (無期限) → サポート branch：feature, release, hotfix (有期限)

Slide 18

Slide 18 text

18 ©MIXI Git Flow： main と develop main と develop 無限 ライフタイムを 持つメイン branch。 ● develop ○ 基本的にこ branch で開発する。 ● main ○ develop branch が安定してリリースする準備が できたら全て 変更を main ブランチに merge する ○ 変更が main に merge されるた に新しい リリース tag を打つ ○ main 先頭が常にプロダクト 最新 リリース になる 参考：A successful Git branching model feature develop release hotfix main

Slide 19

Slide 19 text

19 ©MIXI Git Flow：feature feature 複数人で develop を開発するため サポート branch。 ● 1機能＝1 feature で develop から branch を切る ○ 複数機能＝1 feature デメリットが多い ■ ど 機能がど branch にあるか把握し ずらい ■ 差分が大きくなってコンフリクトしやすい ■ 機能単位で revert しずらい ○ 大きい機能開発 場合 feature からさらに feature を切る ● 機能 開発が終われ develop に merge する ● 機能 開発がうまくいかなけれ 破棄する ○ 実験・実証 feature で実施する 参考：A successful Git branching model feature develop release hotfix main

Slide 20

Slide 20 text

20 ©MIXI Git Flow：release release develop から main へ merge する 「準備」 ため サポート branch。 ● release develop から branch を切る ● 安定した release develop と main に merge する ● チームによって staging と呼ぶかも ● 具体的な「準備」 内容 プロジェクトによる ○ 新規実装を凍結して bugfix みに使う ○ version 表記やタイムスタンプを更新する ● release で新規機能を追加しないようにする (新規機能追加 develop から切った feature で！) 参考：A successful Git branching model feature develop release hotfix main

Slide 21

Slide 21 text

21 ©MIXI Git Flow：hotfix hotfix 本番環境で発生したバグ 内、 緊急性 高いも を即座に対処するため サポート branch。 ● hotfix main から branch を切る ○ develop 以外で唯一 main から切られる branch ● 安定した hotfix develop と main に merge する ● hotfix から main を更新した場合 、patch バージョンをあ げることが多い ○ 1.2 → 1.3 で なく、1.2 → 1.2.1 参考：A successful Git branching model feature develop release hotfix main

Slide 22

Slide 22 text

22 ©MIXI Git Flow：まとめ Git Flow 長期的な開発サイクルと厳密な ルールを持つ。全体像 右図。 大体 チームで Git Flow をそ ままで なく ちょっとアレンジして使っている。 組織やリポジトリ 特性などから適したも を 選 ましょう。 参考：A successful Git branching model feature develop release hotfix main

Slide 23

Slide 23 text

23 ©MIXI Git Flow：アレンジ例 （モンストサーバチーム 場合） ● main, hotfix, feature Git Flow と同じ役割 ● verX.Y-pr, verX.Y-deploy バージョン番号 X.Y 向け機 能を開発する時に作られる branch ○ verX.Y-deploy ■ 開発環境へ反映される ■ 次回バージョン向け差分 他に、本番環境へ 反映している main 向け 差分も取り込んで QA したりする ○ verX.Y-pr ■ ステージング環境などに反映される ■ バージョンアップデートメンテナンス時に main へ merge される ● 複数バージョン開発 ブランチ戦略 詳細 「モンストサーバーで 複数バージョン開発 ブランチ戦略 」 を見 て 参考：モンストサーバーで 複数バージョン開発 ブランチ戦略 verX.Y-deploy feature verX.Y-pr hotfix main

Slide 24

Slide 24 text

24 ©MIXI 他 開発手法 他にもチーム開発を効率的に行うために、シンプルな運用で理解がしやすく、 頻繁にデプロイを行う手法もある。 ● GitHub Flow 軽量 ブランチベース ワークフロー ● トランクベース開発 細かく頻繁にリリースする開発手法 etc…

Slide 25

Slide 25 text

©MIXI 休憩！

Slide 26

Slide 26 text

©MIXI “GitHub を⽤いたチーム開発のノウハウ” を話す前に！ GitHub の機能について

Slide 27

Slide 27 text

©MIXI Q. そもそも、なぜ GitHub？ A. 弊社では GitHub を使⽤しているから Git 単体を使う で なく、リポジトリホスティング サービスと併用することで Git 真価を発揮します

Slide 28

Slide 28 text

28 ©MIXI GitHub 機能 GitHub Git をチームで使うにあたって便利な機能がいっ いある 基本的な機能 リポジトリ トップページ タブでまとめられている

Slide 29

Slide 29 text

29 ©MIXI GitHub 機能 ② Collaborative coding で開発し、 ③ CI/CD and DevOps で開発工程を自動化＆開発と運用を円滑に回す ① Project Management でプロジェクト・タスク管理をしつつ、 ④ そ 他 参考：GitHub Docs

Slide 30

Slide 30 text

30 ©MIXI 開発で大活躍する GitHub 機能 ① Project management 目的：作業 計画、アイデア、フィードバック、タスク、バグ、過程を追跡する

Slide 31

Slide 31 text

31 ©MIXI 開発で大活躍する GitHub 機能 ① Project management 目的：作業 計画、アイデア、フィードバック、タスク、バグ、過程を追跡する

Slide 32

Slide 32 text

32 ©MIXI 開発で大活躍する GitHub 機能 ① Project management 目的：作業 計画、アイデア、フィードバック、タスク、バグ、過程を追跡する Projects アジャイルやスクラム開発でよく使うタスク管理ツール ● 作業 進捗状況を可視化 ● 優先度やマイルストーン、ストーリーポイントを管理 様々なレイアウトがある ● Team Planning ● Feature release ● Kanban ● Bug tracker ● Iterative development ● Product launch ● Roadmap ● Team retrospective 画像引用：GitHub Issues/Projects/ビュー カスタマイズ

Slide 33

Slide 33 text

33 ©MIXI 開発で大活躍する GitHub 機能 ② Collaborative coding 目的：変更が merge される前 レビューとフォローアップをする Q.　なぜ「Merge Request」で なく「 Pull Requests」？

Slide 34

Slide 34 text

34 ©MIXI 開発で大活躍する GitHub 機能 ② Collaborative coding 目的：変更が merge される前 レビューとフォローアップをする Q.　なぜ「Merge Request」で なく「 Pull Requests」？ A. Linux 開発 名残。 特定 branch や fork 元 リポジトリに「私 作業を取り込んでください」と依頼 できる機能だから。「 Pull = 取り込み」 　Linux 開発で、Linus もつメイン リポジトリに自分 作業内容を取り入れてほしいとき 「こ ブランチにあるも を取り込んでください」とお願いしていたことが由来。 　※ git request-pull というコマンドもあるくらい Linux 開発者 「私 作業を Linus 氏 メインリポジトリに 　 取り込んでください。」 Linux と Git パパ Linus Torvalds 氏 「承知しました。レビューします。」 レビュー結果OK：「OKな で取り込みます。」 レビュー結果NG：「ここを直して欲しいです。」 Pull Request コードレビュー Developer Reviewer

Slide 35

Slide 35 text

35 ©MIXI 開発で大活躍する GitHub 機能 ③ CI/CD and DevOps 目的：リポジトリ 内でイベントが発生した 時 ワークフローを実行 する GitHub Actions と GitHub が提供している、ビルド、テスト、デプロイ パイプライン自動化 ため 継続的インテグレーションと継続的デリバリー (CI/CD) プラットフォーム Actions を使うメリットたくさん！ ● GitHub 上にあるコードをそ まま使用し、他 サービスと連携させる必要がなく簡単に導入し使用できる ● エコシステムが充実している ● パブリックリポジトリ 無料で使用できる ● Hook したいイベントとワークフローを書いた yaml を .github/workflows/ に配置すると 勝手に走ってくれる ○ GitHub で公開されている actions/starter-workflows にたくさん yaml 例がある

Slide 36

Slide 36 text

36 ©MIXI ● Security ○ Security policy … 脆弱性報告 手順をユーザーに示す ○ Security advisories … 非公開で脆弱性について議論・対策し、解決後 公開できる ○ Dependabot alerts … 脆弱性 ある依存関係を使用していれ 検出しアラートを飛 す ○ Code scanning alerts … コードをスキャンして隠された脆弱性を検出する ● Insights ○ リポジトリ 活発度を様々な指標で確認できる ■ 時系列で commit 数や差分 量がグラフ化されている ■ メンテ具合がわかりやすい（新しいライブラリやツール 導入検討に便利） ● Settings ○ リポジトリ 設定を変える ■ デフォルト branch 変更、merge に関するルール設定、etc… ■ (重要) Branch protection rules (直 push 禁止や force push 禁止) ■ (注意) private → public 変更、オーナー権限 委譲、リポジトリ 削除 開発で大活躍する GitHub 機能 ④ そ 他

Slide 37

Slide 37 text

©MIXI 休憩！

Slide 38

Slide 38 text

©MIXI GitHub を⽤いたチーム開発のノウハウ

Slide 39

Slide 39 text

©MIXI    Q. なぜ チーム開発についての講義をするの？    A. MIXI ではチームで開発をしているから 　　　こ 講義で ハードスキル (技術力 )で なく、チーム開発 要と 　　　なるソフトスキル (コミュニケーション力 ) お話をします Engineering is easy. People are hard. by BILL COUGHRAN Bill Coughran | Sequoia Capital

Slide 40

Slide 40 text

40 ©MIXI 大前提 チーム開発 、チームごとにお作法・文化が異なります。 こ 講義で MIXI 各部署・各チーム、入社 3年目 先輩達 GitHub を用いたチーム開発 仕方や工夫について紹介していきます。 必ずしも真似する必要 ありません。よそ よそうち うち、です。 チームに合わせてより良い開発方法を模索していってください。 ヒアリング対象： 私(飯島)も含めた22新卒、入社 3年目 エンジニア 11名 「チーム」で チーム開発 仕方や工夫だよ 「個人」で チーム開発 仕方や工夫だよ

Slide 41

Slide 41 text

©MIXI Q. チーム開発で⼤切なことは？

Slide 42

Slide 42 text

©MIXI  Q. チーム開発で⼤切なことは？  A. 『HRT』from Team Geek 謙虚(Humility) 世界 中心 君で ない。君 全知全能で ないし、絶対に正しいわけでもない。 常に自分を改善していこう。 尊敬(Respect) 一緒に働く人 ことを心から思いやろう。相手を 1人 人間として扱い、 そ 能力や功績を高く評価しよう。 信頼(Trust) 自分以外 人 有能であり、正しいことをすると信じよう。 そうすれ 仕事を任せることができる。 ※ 読み方 「ハート (heart)」 出典「Team Geek – Google ギークたち いかにしてチームを作る か」 P15 参考 Understanding Team Effectiveness, Google Research いい仕事をして成果を出すに 『チームが重要』 そ ために チーム 『心理的安全性を高める』 ことが大切

Slide 43

Slide 43 text

©MIXI  Q. チーム開発で⼤切なことは？  A. 『HRT』from Team Geek 謙虚(Humility) 世界 中心 君で ない。君 全知全能で ないし、絶対に正しいわけでもない。 常に自分を改善していこう。 尊敬(Respect) 一緒に働く人 ことを心から思いやろう。相手を 1人 人間として扱い、 そ 能力や功績を高く評価しよう。 信頼(Trust) 自分以外 人 有能であり、正しいことをすると信じよう。 そうすれ 仕事を任せることができる。 ※ 読み方 「ハート (heart)」 余談：「謙虚」と「謙遜」 違い 「謙虚」 　持続的な状態。相手 考えや気持ちを素直に受け取る。 　→ 自分にも周りにもポジティブな影響がある (人を寄せ付ける) 「謙遜」 　一時的な行為。自分 能力や価値などを下げて評価する。 　→ 周りにネガティブな影響がある (人を遠ざける) 「ありがとう」 相手 言葉を受け入れて肯定 「いえいえ、そんな..」 相手 言葉を受け入れず否定 ※シチュエーション例 「褒められた時」 出典「Team Geek – Google ギークたち いかにしてチームを作る か」 P15 参考 Understanding Team Effectiveness, Google Research

Slide 44

Slide 44 text

©MIXI  Q. チーム開発で⼤切なことは？  別解. 『気遣い』from ヒアリング回答分析結果 　　① 「書くこと」： GitHub 上で何かを出す 　　　 → 何か... Code, Issue, Commit, Pull request, Review, etc 　　② 「読むこと」：自分や他者がそれを見て理解する 　　読んでいる時間 >>>>>>>> 書いている時間 　　読んでいる時間 書いている時間より るかに長くなる 　　・現在 チームメンバー 読む作業をどれだけ短縮できるか 　　・未来 チームメンバーがどれだけ歴史を辿りやすいか 　　・未来 自分がまた同じも を見た時にすぐに内容を思い出せるか 『気遣い』 伝わりやすく 丁寧に理解しやすく 『書く』 『読む』時間が 短縮される 開発効率が上がる！

Slide 45

Slide 45 text

©MIXI  Q. チーム開発で⼤切なことは？  別解. 『気遣い』from ヒアリング回答分析結果 　　① 「書くこと」： GitHub 上で何かを出す 　　　 → 何か... Code, Issue, Commit, Pull request, Review, etc 　　② 「読むこと」：自分や他者がそれを見て理解する 　　読んでいる時間 >>>>>>>> 書いている時間 　　読んでいる時間 書いている時間より るかに長くなる 　　・現在 チームメンバー 読む作業をどれだけ短縮できるか 　　・未来 チームメンバーがどれだけ歴史を辿りやすいか 　　・未来 自分がまた同じも を見た時にすぐに内容を思い出せるか 『気遣い』 伝わりやすく 丁寧に理解しやすく 『書く』 『読む』時間が 短縮される 開発効率が上がる 次 スライドから 、 入社3年目 先輩たち or 各部署チームがチーム開発において ど ような工夫をしている かを紹介していきます。 そこからわかる『気遣い』をぜ 皆さんも習得し、 『気遣い』 できるエンジニアになってください。

Slide 46

Slide 46 text

46 ©MIXI 大前提（再） チーム開発 、チームごとにお作法・文化が異なります。 こ 講義で MIXI 各部署・各チーム、入社 3年目 先輩達 GitHub を用いたチーム開発 仕方や工夫について紹介していきます。 必ずしも真似する必要 ありません。よそ よそうち うち、です。 チームに合わせてより良い開発方法を模索していてください。 ヒアリング対象： 私(飯島)も含めた22新卒、入社 3年目 エンジニア 11名 「チーム」で チーム開発 仕方や工夫だよ 「個人」で チーム開発 仕方や工夫だよ

Slide 47

Slide 47 text

47 ©MIXI Issues と Projects に関わるノウハウ Issues も Projects も 使用していなくて別 管理ツール を使用しているよ Issues と Projects を 併用しているよ Issues だけ使用しているよ 入社3年目 先輩たち or 各部署チーム 工夫紹介 Q. Issues 書き方 ？ 好き勝手書いてるよ Issue Template を使用しているよ（理由 以下） 　・フォーマットが揃っている で概要把握しやすいから 　・見るべき重要な事柄をすぐ探すことができるため、考古学がしやすいから 　・ある程度 概要 記述を強制し、情報 不足がないようにするため etc… 気になったことを書く やったことを書く 調べたことを書く 考古学(git log, git blame) 時間を短縮するため 情報を入れるよ Q. Issues と Projects どっち使ってる？

Slide 48

Slide 48 text

48 ©MIXI Issues と Projects に関わるノウハウ Issues も Projects も 使用していなくて別 管理ツール を使用しているよ Issues と Projects を 併用しているよ Issues だけ使用しているよ 入社3年目 先輩たち or 各部署チーム 工夫紹介 Q. Issues 書き方 ？ 好き勝手書いてるよ Issue Template を使用しているよ（理由 以下） 　・フォーマットが揃っている で概要把握しやすいから 　・見るべき重要な事柄をすぐ探すことができるため、考古学がしやすいから 　・ある程度 概要 記述を強制し、情報 不足がないようにするため etc… 気になったことを書く やったことを書く 調べたことを書く 考古学(git log, git blame) 時間を短縮するため 情報を入れるよ Q. Issues と Projects どっち使ってる？

Slide 49

Slide 49 text

49 ©MIXI 入社3年目 先輩たち or 各部署チーム 工夫紹介 丁寧に「伝える努力」をするよ ・テキストだけで なく動画や画像を添付する → 画像 境界 枠線を入れてわかりやすいように ・GitHub 上 コード引用時 permalink を使う ・リンク ど 部分を見た かを引用で紹介する ・ラベルを大活用 ・関連するリンクを紐付ける 　(Issues, Pull Requests, Milestone, Projects) → GitHub 上 関連リンク タイトルを表示させる etc… Issues と Projects に関わるノウハウ

Slide 50

Slide 50 text

50 ©MIXI ある日突然、あなた 大切なリポジトリにこ ような Pull Request が飛んできました。こ 差分を取り込みますか？ Pull Requests に関わるノウハウ 入社3年目 先輩たち or 各部署チーム 工夫紹介 そ 前に...

Slide 51

Slide 51 text

51 ©MIXI ある日突然、あなた 大切なリポジトリにこ ような Pull Request が飛んできました。こ 差分を取り込みますか？ Pull Requests に関わるノウハウ 入社3年目 先輩たち or 各部署チーム 工夫紹介 そ 前に...

Slide 52

Slide 52 text

52 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 GitHub Flow と 、短期間で頻繁なリリースを目的と する軽量 ブランチベース ワークフロー こと。 GitHub Flow 開発手順に沿って紹介していきます。 Pull Requests に関わるノウハウ

Slide 53

Slide 53 text

53 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 branch を切る時・向き先に ルールがあったりするよ (Git Flow など...) branch 命名規則が あったりするよ branch 名を決める が難しい時 detach を駆使(branch がない状態) して、ある程度整理されてきてから branch 名を付けるよ → とりあえず素早くコードを書かないといけない時 工夫 Q. branch 作成にルールがある？ Q. branch 名 命名に困ったら？ Pull Requests に関わるノウハウ

Slide 54

Slide 54 text

54 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 branch を切る時・向き先に ルールがあったりするよ (Git Flow など...) branch 命名規則が あったりするよ branch 名を決める が難しい時 detach を駆使(branch がない状態) して、ある程度整理されてきてから branch 名を付けるよ → とりあえず素早くコードを書かないといけない時 工夫 Q. branch 作成にルールがある？ Q. branch 名 命名に困ったら？ Pull Requests に関わるノウハウ

Slide 55

Slide 55 text

55 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 無法です！ 英語で書く人もいれ 、 日本語で書く人もいて カオスだけど、特に問題 発生していない で ルール 決めてないよ commit ログ 適当でOK！なぜなら、あとで全部消すから！ Pull Request 作成時に squash merge で1つ commit にまとめて出すルールがあるよ 履歴を気にせず好き勝手 commit できて開発効率を上げるためだよ (Pull Request 作成後 修正 レビュアーが変更が見やすいように commit 積むよ) commit ログ しっかり書く！なぜなら、ずっと残すから！ commit ログ 変更 追跡がしやすいように、 自分 ため・チーム ために分かりやすく簡潔に、丁寧に綺麗に残すよ！ 「丁寧に」 ・意味 ある小さな単位で、 commit メッセージと commit 内容が相違しないように積む ・「レビュー箇所を修正」など他コンテキスト 情報がないとわからない NG ・fix, feat, add, remove など prefix を付けて変更 意図を伝える ・commit メッセージに関連リンクを記載してコード内検索で類似実装を探しやすくする 「綺麗に」 ・commit --amend で適切な粒度に commit をまとめておく ・git rebase -i で commit 体裁を整える (修正やリフォーマット 他 commit に混ぜる) Q. commit ログ 残し方にルールがある？ Pull Requests に関わるノウハウ

Slide 56

Slide 56 text

56 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 無法です！ 英語で書く人もいれ 、 日本語で書く人もいて カオスだけど、特に問題 発生していない で ルール 決めてないよ commit ログ 適当でOK！なぜなら、あとで全部消すから！ Pull Request 作成時に squash merge で1つ commit にまとめて出すルールがあるよ 履歴を気にせず好き勝手 commit できて開発効率を上げるためだよ (Pull Request 作成後 修正 レビュアーが変更が見やすいように commit 積むよ) commit ログ しっかり書く！なぜなら、ずっと残すから！ commit ログ 変更 追跡がしやすいように、 自分 ため・チーム ために分かりやすく簡潔に、丁寧に綺麗に残すよ！ 「丁寧に」 ・意味 ある小さな単位で、 commit メッセージと commit 内容が相違しないように積む ・「レビュー箇所を修正」など他コンテキスト 情報がないとわからない NG ・fix, feat, add, remove など prefix を付けて変更 意図を伝える ・commit メッセージに関連リンクを記載してコード内検索で類似実装を探しやすくする 「綺麗に」 ・commit --amend で適切な粒度に commit をまとめておく ・git rebase -i で commit 体裁を整える (修正やリフォーマット 他 commit に混ぜる) Q. commit ログ 残し方にルールがある？ Pull Requests に関わるノウハウ

Slide 57

Slide 57 text

57 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 無法です！ 英語で書く人もいれ 、 日本語で書く人もいて カオスだけど、特に問題 発生していない で ルール 決めてないよ commit ログ 適当でOK！なぜなら、あとで全部消すから！ Pull Request 作成時に squash merge で1つ commit にまとめて出すルールがあるよ 履歴を気にせず好き勝手 commit できて開発効率を上げるためだよ (Pull Request 作成後 修正 レビュアーが変更が見やすいように commit 積むよ) commit ログ しっかり書く！なぜなら、ずっと残すから！ commit ログ 変更 追跡がしやすいように、 自分 ため・チーム ために分かりやすく簡潔に、丁寧に綺麗に残すよ！ 「丁寧に」 ・意味 ある小さな単位で、 commit メッセージと commit 内容が相違しないように積む ・「レビュー箇所を修正」など他コンテキスト 情報がないとわからない NG ・fix, feat, add, remove など prefix を付けて変更 意図を伝える ・commit メッセージに関連リンクを記載してコード内検索で類似実装を探しやすくする 「綺麗に」 ・commit --amend で適切な粒度に commit をまとめておく ・git rebase -i で commit 体裁を整える (修正やリフォーマット 他 commit に混ぜる) Q. commit ログ 残し方にルールがある？ Pull Requests に関わるノウハウ

Slide 58

Slide 58 text

58 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 動かない commit 作るなという声もあるかもですが、 レビュー しやすさを優先 しています！ 例：不具合修正 時 1. まずテスト追加を commit 2. コード修正を commit 3. テストが落ちる commit にチェックアウトすることでレビューがしやすい 4. 修正した commit でテストが落ちないことを確認できてレビューがしやすい Q. pre-commit (commit を確定する前に実行されるフック ) 使ってる？ main とか release branch へ commit を禁止する設定を入れてるよ Q. commit 順にこだわり ある？ 文法やスタイルチェックをする設定を入れてるよ Pull Requests に関わるノウハウ

Slide 59

Slide 59 text

59 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 動かない commit 作るなという声もあるかもですが、 レビュー しやすさを優先 しています！ 例：不具合修正 時 1. まずテスト追加を commit 2. コード修正を commit 3. テストが落ちる commit にチェックアウトすることでレビューがしやすい 4. 修正した commit でテストが落ちないことを確認できてレビューがしやすい Q. pre-commit (commit を確定する前に実行されるフック ) 使ってる？ main とか release branch へ commit を禁止する設定を入れてるよ Q. commit 順にこだわり ある？ 文法やスタイルチェックをする設定を入れてるよ Pull Requests に関わるノウハウ

Slide 60

Slide 60 text

60 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 無駄な差分を入れず差分が多くならないように 意味 ある小さな単位で出す Q. なぜ巨大な Pull Request ダメな ？ A. レビューに時間がかかり、開発効率が悪くなるから！ → レビュアーが理解する に時間がかかる (開発 遅延) 　→ 時間がかかると merge まで 時間も当然 る 　　→ 別 Pull Request がどんどん先に merge されていく 　　　→ さらにコンフリクト 解消に失敗してバグるかも → 見る範囲が多くてレビュアーがバグを見落とすかも → 時間がかかりそうだと思われて後回しにされるかも 巨大にならざるをえないとき 、途中でレビューしてもらおう！ ・Git Flow で少し話した、feature から feature を切るテクニックを駆使する ・最初 feature タイトルに WIP をつけたり Draft Pull Request として出す Q. Pull Request サイズ どうしている？ Pull Requests に関わるノウハウ

Slide 61

Slide 61 text

61 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 読む人 認知コストをできるだけ下げるために、丁寧に「伝える努力」をするよ ・基本 Issues 『丁寧に「伝える努力」をするよ』と同じ ・Pull Request Template を使用したりしなかったり (使用理由 Issues Template と同じ) ・できるだけ誰でも＆何も知らない人でもレビューできるように description を書く ・動画 撮り方や画像編集にこだわり、手書きも駆使してとにかく状況を早く正確に伝える ・Pull Request 想像以上に遡って見られるということを意識して詳細に記載する → git blame から来る人 ことも考えている ・議論できそうなところや特に見てほしいところ、懸念点がある場所 あらかじめ書いておく ・必要な場合 コード内に自分でコメント (「何」で なく「なぜ」 )して補足したりする ・動作確認など実際に動いている証拠を貼ったり、 SQL がある場合に 実行計画を貼る 一方で... Pull Request を出す段階で なく、実装する前 段階で設計・仕様 認識合わせ ある程度チーム内で済ませておく で description 書きすぎない Q. レビュー開始に向けてどんな工夫をしている？ レビュー前にセルフレビュー！ 意外と実装中に気づかなかった 問題点が見つかることも多い で セルフレビュー おすすめ！ タイトルに WIP をつけたり Draft Pull Request として出してレビュアー フライングを防ぐ レビューして欲しい人が決まっていれ Review Requestを送る or レビュアーを自動で割り当て Pull Requests に関わるノウハウ

Slide 62

Slide 62 text

62 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 読む人 認知コストをできるだけ下げるために、丁寧に「伝える努力」をするよ ・基本 Issues 『丁寧に「伝える努力」をするよ』と同じ ・Pull Request Template を使用したりしなかったり (使用理由 Issues Template と同じ) ・できるだけ誰でも＆何も知らない人でもレビューできるように description を書く ・動画 撮り方や画像編集にこだわり、手書きも駆使してとにかく状況を早く正確に伝える ・Pull Request 想像以上に遡って見られるということを意識して詳細に記載する → git blame から来る人 ことも考えている ・議論できそうなところや特に見てほしいところ、懸念点がある場所 あらかじめ書いておく ・必要な場合 コード内に自分でコメント (「何」で なく「なぜ」 )して補足したりする ・動作確認など実際に動いている証拠を貼ったり、 SQL がある場合に 実行計画を貼る 一方で... Pull Request を出す段階で なく、実装する前 段階で設計・仕様 認識合わせ ある程度チーム内で済ませておく で description 書きすぎない Q. レビュー開始に向けてどんな工夫をしている？ レビュー前にセルフレビュー！ 意外と実装中に気づかなかった 問題点が見つかることも多い で セルフレビュー おすすめ！ タイトルに WIP をつけたり Draft Pull Request として出してレビュアー フライングを防ぐ レビューして欲しい人が決まっていれ Review Requestを送る or レビュアーを自動で割り当て Pull Requests に関わるノウハウ

Slide 63

Slide 63 text

63 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 読む人 認知コストをできるだけ下げるために、丁寧に「伝える努力」をするよ ・基本 Issues 『丁寧に「伝える努力」をするよ』と同じ ・Pull Request Template を使用したりしなかったり (使用理由 Issues Template と同じ) ・できるだけ誰でも＆何も知らない人でもレビューできるように description を書く ・動画 撮り方や画像編集にこだわり、手書きも駆使してとにかく状況を早く正確に伝える ・Pull Request 想像以上に遡って見られるということを意識して詳細に記載する → git blame から来る人 ことも考えている ・議論できそうなところや特に見てほしいところ、懸念点がある場所 あらかじめ書いておく ・必要な場合 コード内に自分でコメント (「何」で なく「なぜ」 )して補足したりする ・動作確認など実際に動いている証拠を貼ったり、 SQL がある場合に 実行計画を貼る 一方で... Pull Request を出す段階で なく、実装する前 段階で設計・仕様 認識合わせ ある程度チーム内で済ませておく で description 書きすぎない Q. レビュー開始に向けてどんな工夫をしている？ レビュー前にセルフレビュー！ 意外と実装中に気づかなかった 問題点が見つかることも多い で セルフレビュー おすすめ！ タイトルに WIP をつけたり Draft Pull Request として出してレビュアー フライングを防ぐ レビューして欲しい人が決まっていれ Review Requestを送る or レビュアーを自動で割り当て Pull Requests に関わるノウハウ

Slide 64

Slide 64 text

64 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 読む人 認知コストをできるだけ下げるために、丁寧に「伝える努力」をするよ ・基本 Issues 『丁寧に「伝える努力」をするよ』と同じ ・Pull Request Template を使用したりしなかったり (使用理由 Issues Template と同じ) ・できるだけ誰でも＆何も知らない人でもレビューできるように description を書く ・動画 撮り方や画像編集にこだわり、手書きも駆使してとにかく状況を早く正確に伝える ・Pull Request 想像以上に遡って見られるということを意識して詳細に記載する → git blame から来る人 ことも考えている ・議論できそうなところや特に見てほしいところ、懸念点がある場所 あらかじめ書いておく ・必要な場合 コード内に自分でコメント (「何」で なく「なぜ」 )して補足したりする ・動作確認など実際に動いている証拠を貼ったり、 SQL がある場合に 実行計画を貼る 一方で... Pull Request を出す段階で なく、実装する前 段階で設計・仕様 認識合わせ ある程度チーム内で済ませておく で description 書きすぎない Q. レビュー開始に向けてどんな工夫をしている？ レビュー前にセルフレビュー！ 意外と実装中に気づかなかった 問題点が見つかることも多い で セルフレビュー おすすめ！ タイトルに WIP をつけたり Draft Pull Request として出してレビュアー フライングを防ぐ レビューして欲しい人が決まっていれ Review Requestを送る or レビュアーを自動で割り当て Pull Requests に関わるノウハウ

Slide 65

Slide 65 text

65 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 そ 前に... 皆さん コードレビューを 積極的にしていますか？ Pull Requests に関わるノウハウ

Slide 66

Slide 66 text

66 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 そ 前に... 皆さん コードレビューを 積極的にしていますか？ 知識・技術力不足 不安 「私、まだコード 良し悪しがよくわからなくて … レビューでちゃんと役に立つ意見を言えるかわからないです」 「レビューって経験豊富な人がするも だと思ってました 私みたいに経験 浅い人間がやっても、本当に貢献できるんですか ？」 レビューに対する誤解 「レビュー 人 コードを批判することな で そんなことをして人間関係を悪くしたくないなあ …」 「レビューっていう 時間がかかる作業だと思うんです もっとコーディングに集中してチーム 役に立ちたいです」 タイムマネジメント・取り組み方 不安 「レビューしたいが、自分 タスクで手一杯です 時間をどうやって管理したらいい かコツが掴めないです」 「レビュー 仕方を学んだことがない で どうやっていい か、どこから手をつけていい か …」 Pull Requests に関わるノウハウ

Slide 67

Slide 67 text

67 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 そ 前に... 皆さん コードレビューを 積極的にしていますか？ 知識・技術力不足 不安 「私、まだコード 良し悪しがよくわからなくて … レビューでちゃんと役に立つ意見を言えるかわからないです」 「レビューって経験豊富な人がするも だと思ってました 私みたいに経験 浅い人間がやっても、本当に貢献できるんですか ？」 レビューに対する誤解 「レビュー 人 コードを批判することな で そんなことをして人間関係を悪くしたくないなあ …」 「レビューっていう 時間がかかる作業だと思うんです もっとコーディングに集中してチーム 役に立ちたいです」 タイムマネジメント・取り組み方 不安 「レビューしたいが、自分 タスクで手一杯です 時間をどうやって管理したらいい かコツが掴めないです」 「レビュー 仕方を学んだことがない で どうやっていい か、どこから手をつけていい か …」 コードレビューが一番勉強になります！ チームで活躍したいなら まず コードレビューから始めましょう！ Pull Requests に関わるノウハウ

Slide 68

Slide 68 text

68 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 レビューに対する誤解 「レビュー 人 コードを批判することな で そんなことをして人間関係を悪くしたくないなあ…」 「レビューっていう 時間がかかる作業だと思うんです もっとコーディングに集中してチーム 役に立ちたいです」 ・テキストで 指摘 結構キツく感じてしまいがちな で、普段 1.5倍優しい言葉遣い、ギャグみたいに丁寧な言葉遣いをする ・未来 自分やチームメンバーに向けたメッセージにもなる で、必ずコメントを残すようにする 　① 質問・確認コメント：自分以外 メンバーも同じ疑問を持っているかもしれない、チームメンバー全員と認識を合わせる 　② 賞賛コメント：グッときたコードに :heart: 、「これ 賢い！」とか素直に賞賛する、賞賛コメントもらえると普通に嬉しい 　③ メモコメント：Pull Request 説明とコードだけで情報が足りず別 サイトを参照したり口頭解決した時 、他 人用にメモを残す 　④ 指摘・提案コメント：抽象的な言い方「こ コード よくない」 せず、理由と根拠となることを必ず書く 　 　 　→ 合わせて、どういう方法なら良い かも書けると議論もしやすい ( suggestion とか使う) 　 　 　→ 気を遣って遠回しに言うくらいならハッキリ書こう 　 　 　→ 意図や重要度を明確にしておく (prefix を使う IMO,Q,NITS,MEMO, etc... ) ・レビューすることでコード 改善や品質を保つことができ、 ・目が増えることでリスクヘッジに繋がり、 ・変更に対する認識を合わせることで属人化を防ぐことができる 入社3年目 先輩たち or 各部署チーム 工夫紹介 Q. どんなレビューコメントをする？ Pull Requests に関わるノウハウ

Slide 69

Slide 69 text

69 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 レビューに対する誤解 「レビュー 人 コードを批判することな で そんなことをして人間関係を悪くしたくないなあ…」 「レビューっていう 時間がかかる作業だと思うんです もっとコーディングに集中してチーム 役に立ちたいです」 ・テキストで 指摘 結構キツく感じてしまいがちな で、普段 1.5倍優しい言葉遣い、ギャグみたいに丁寧な言葉遣いをする ・未来 自分やチームメンバーに向けたメッセージにもなる で、必ずコメントを残すようにする 　① 質問・確認コメント：自分以外 メンバーも同じ疑問を持っているかもしれない、チームメンバー全員と認識を合わせる 　② 賞賛コメント：グッときたコードに :heart: 、「これ 賢い！」とか素直に賞賛する、賞賛コメントもらえると普通に嬉しい 　③ メモコメント：Pull Request 説明とコードだけで情報が足りず別 サイトを参照したり口頭解決した時 、他 人用にメモを残す 　④ 指摘・提案コメント：抽象的な言い方「こ コード よくない」 せず、理由と根拠となることを必ず書く 　 　 　→ 合わせて、どういう方法なら良い かも書けると議論もしやすい ( suggestion とか使う) 　 　 　→ 気を遣って遠回しに言うくらいならハッキリ書こう 　 　 　→ 意図や重要度を明確にしておく (prefix を使う IMO,Q,NITS,MEMO, etc... ) ・レビューすることでコード 改善や品質を保つことができ、 ・目が増えることでリスクヘッジに繋がり、 ・変更に対する認識を合わせることで属人化を防ぐことができる 入社3年目 先輩たち or 各部署チーム 工夫紹介 Q. どんなレビューコメントをする？ Pull Requests に関わるノウハウ

Slide 70

Slide 70 text

70 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 知識・技術力不足 不安 「私、まだコード 良し悪しがよくわからなくて… レビューでちゃんと役に立つ意見を言えるかわからないです」 「レビューって経験豊富な人がするも だと思ってました 私みたいに経験 浅い人間がやっても、本当に貢献できるんですか ？」 新人だから気づく新鮮な視点を チームメンバーに提供できる 入社3年目 先輩たち or 各部署チーム 工夫紹介 レビュアーによって視点 様々で、レビュー 得意分野があったりする ・Aさん 文法やスタイル 間違いを見つける が得意 ・Bさん 読みやすさをまず一番に気にしている ・Cさん 無駄な記述を極力減らそうとしてくれている ・Dさん クリティカルな設計ミスを瞬時に見つけてくれる コメントがいっ いついている Pull Request を見て、みんなどんな観点で見てる か、何が問題になりやすい かを学 、できるだけ事前にリスクを察知できるよう にする 人が書いたコード 読む練習になる → エンジニア 仕事：書く <<<<<<<<<<< 読む → 早いうちから読むことに慣れておく → コードを読むことでコード 書き方を学べる レビュー チーム全体 学習を促進する機会を提供する レビュー とても勉 強になる！ 自分が1番最初 レビュアーになり、後に続くレビュアー コメントも しっかり読むことで、自分が気づかなかった視点・考えを学ぶ Pull Requests に関わるノウハウ

Slide 71

Slide 71 text

71 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 知識・技術力不足 不安 「私、まだコード 良し悪しがよくわからなくて… レビューでちゃんと役に立つ意見を言えるかわからないです」 「レビューって経験豊富な人がするも だと思ってました 私みたいに経験 浅い人間がやっても、本当に貢献できるんですか ？」 新人だから気づく新鮮な視点を チームメンバーに提供できる 入社3年目 先輩たち or 各部署チーム 工夫紹介 レビュアーによって視点 様々で、レビュー 得意分野があったりする ・Aさん 文法やスタイル 間違いを見つける が得意 ・Bさん 読みやすさをまず一番に気にしている ・Cさん 無駄な記述を極力減らそうとしてくれている ・Dさん クリティカルな設計ミスを瞬時に見つけてくれる コメントがいっ いついている Pull Request を見て、みんなどんな観点で見てる か、何が問題になりやすい かを学 、できるだけ事前にリスクを察知できるよう にする 人が書いたコード 読む練習になる → エンジニア 仕事：書く <<<<<<<<<<< 読む → 早いうちから読むことに慣れておく → コードを読むことでコード 書き方を学べる レビュー チーム全体 学習を促進する機会を提供する レビュー とても勉 強になる！ 自分が1番最初 レビュアーになり、後に続くレビュアー コメントも しっかり読むことで、自分が気づかなかった視点・考えを学ぶ Pull Requests に関わるノウハウ

Slide 72

Slide 72 text

72 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 知識・技術力不足 不安 「私、まだコード 良し悪しがよくわからなくて… レビューでちゃんと役に立つ意見を言えるかわからないです」 「レビューって経験豊富な人がするも だと思ってました 私みたいに経験 浅い人間がやっても、本当に貢献できるんですか ？」 新人だから気づく新鮮な視点を チームメンバーに提供できる 入社3年目 先輩たち or 各部署チーム 工夫紹介 レビュアーによって視点 様々で、レビュー 得意分野があったりする ・Aさん 文法やスタイル 間違いを見つける が得意 ・Bさん 読みやすさをまず一番に気にしている ・Cさん 無駄な記述を極力減らそうとしてくれている ・Dさん クリティカルな設計ミスを瞬時に見つけてくれる コメントがいっ いついている Pull Request を見て、みんなどんな観点で見てる か、何が問題になりやすい かを学 、できるだけ事前にリスクを察知できるよう にする レビュー チーム全体 学習を促進する機会を提供する レビュー とても勉 強になる！ 自分が1番最初 レビュアーになり、後に続くレビュアー コメントも しっかり読むことで、自分が気づかなかった視点・考えを学ぶ Pull Requests に関わるノウハウ 人が書いたコード 読む練習になる → エンジニア 仕事：書く <<<<<<<<<<< 読む → 早いうちから読むことに慣れておく → コードを読むことでコード 書き方を学べる

Slide 73

Slide 73 text

73 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 知識・技術力不足 不安 「私、まだコード 良し悪しがよくわからなくて… レビューでちゃんと役に立つ意見を言えるかわからないです」 「レビューって経験豊富な人がするも だと思ってました 私みたいに経験 浅い人間がやっても、本当に貢献できるんですか ？」 新人だから気づく新鮮な視点を チームメンバーに提供できる 入社3年目 先輩たち or 各部署チーム 工夫紹介 レビュアーによって視点 様々で、レビュー 得意分野があったりする ・Aさん 文法やスタイル 間違いを見つける が得意 ・Bさん 読みやすさをまず一番に気にしている ・Cさん 無駄な記述を極力減らそうとしてくれている ・Dさん クリティカルな設計ミスを瞬時に見つけてくれる コメントがいっ いついている Pull Request を見て、みんなどんな観点で見てる か、何が問題になりやすい かを学 、できるだけ事前にリスクを察知できるよう にする 人が書いたコード 読む練習になる → エンジニア 仕事：書く <<<<<<<<<<< 読む → 早いうちから読むことに慣れておく → コードを読むことでコード 書き方を学べる レビュー チーム全体 学習を促進する機会を提供する レビュー とても勉 強になる！ 自分が1番最初 レビュアーになり、後に続くレビュアー コメントも しっかり読むことで、自分が気づかなかった視点・考えを学ぶ Pull Requests に関わるノウハウ

Slide 74

Slide 74 text

74 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 知識・技術力不足 不安 「私、まだコード 良し悪しがよくわからなくて… レビューでちゃんと役に立つ意見を言えるかわからないです」 「レビューって経験豊富な人がするも だと思ってました 私みたいに経験 浅い人間がやっても、本当に貢献できるんですか ？」 新人だから気づく新鮮な視点を チームメンバーに提供できる 入社3年目 先輩たち or 各部署チーム 工夫紹介 レビュアーによって視点 様々で、レビュー 得意分野があったりする ・Aさん 文法やスタイル 間違いを見つける が得意 ・Bさん 読みやすさをまず一番に気にしている ・Cさん 無駄な記述を極力減らそうとしてくれている ・Dさん クリティカルな設計ミスを瞬時に見つけてくれる コメントがいっ いついている Pull Request を見て、みんなどんな観点で見てる か、何が問題になりやすい かを学 、できるだけ事前にリスクを察知できるよう にする 人が書いたコード 読む練習になる → エンジニア 仕事：書く <<<<<<<<<<< 読む → 早いうちから読むことに慣れておく → コードを読むことでコード 書き方を学べる レビュー チーム全体 学習を促進する機会を提供する レビュー とても勉 強になる！ 自分が1番最初 レビュアーになり、後に続くレビュアー コメントも しっかり読むことで、自分が気づかなかった視点・考えを学ぶ Pull Requests に関わるノウハウ

Slide 75

Slide 75 text

75 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 タイムマネジメント・取り組み方 不安 「レビューしたいが、自分 タスクで手一杯です 時間をどうやって管理したらいい かコツが掴めないです」 「レビュー 仕方を学んだことがない で どうやっていい か、どこから手をつけていい か…」 ・まず Pull Request で実現したいことや仕様を把握する ・レビュー対象 差分を必ずローカルに持ってくる 　→ 自分がよく使うエディタ上からレビューする 　→ 慣れているツールでコンテキスト全体を把握するため 　→ (GitHub ブラウザ上でレビューしない ) 人によって様々な で自分に合った「レビュー習慣」を身につけよう 入社3年目 先輩たち or 各部署チーム 工夫紹介 ・「好きな時間で1日最低1レビュー以上」を習慣化しているよ ・毎日午前中 レビューしてるよ ・昼食後にレビュータイム設けているよ ・コーディングに疲れたら息抜きにレビューしてるよ ・Pull Request が出たタイミングですぐにレビューしてるよ Q. ど タイミングでレビューしてる？ Q. レビューする前 下準備 ？ Pull Requests に関わるノウハウ

Slide 76

Slide 76 text

76 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 タイムマネジメント・取り組み方 不安 「レビューしたいが、自分 タスクで手一杯です 時間をどうやって管理したらいい かコツが掴めないです」 「レビュー 仕方を学んだことがない で どうやっていい か、どこから手をつけていい か…」 ・まず Pull Request で実現したいことや仕様を把握する ・レビュー対象 差分を必ずローカルに持ってくる 　→ 自分がよく使うエディタ上からレビューする 　→ 慣れているツールでコンテキスト全体を把握するため 　→ (GitHub ブラウザ上でレビューしない ) 人によって様々な で自分に合った「レビュー習慣」を身につけよう 入社3年目 先輩たち or 各部署チーム 工夫紹介 ・「好きな時間で1日最低1レビュー以上」を習慣化しているよ ・毎日午前中 レビューしてるよ ・昼食後にレビュータイム設けているよ ・コーディングに疲れたら息抜きにレビューしてるよ ・Pull Request が出たタイミングですぐにレビューしてるよ Q. ど タイミングでレビューしてる？ Q. レビューする前 下準備 ？ Pull Requests に関わるノウハウ

Slide 77

Slide 77 text

77 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 タイムマネジメント・取り組み方 不安 「レビューしたいが、自分 タスクで手一杯です 時間をどうやって管理したらいい かコツが掴めないです」 「レビュー 仕方を学んだことがない で どうやっていい か、どこから手をつけていい か…」 ・まず Pull Request で実現したいことや仕様を把握する ・レビュー対象 差分を必ずローカルに持ってくる 　→ 自分がよく使うエディタ上からレビューする 　→ 慣れているツールでコンテキスト全体を把握するため 　→ (GitHub ブラウザ上でレビューしない ) 人によって様々な で自分に合った「レビュー習慣」を身につけよう 入社3年目 先輩たち or 各部署チーム 工夫紹介 ・「好きな時間で1日最低1レビュー以上」を習慣化しているよ ・毎日午前中 レビューしてるよ ・昼食後にレビュータイム設けているよ ・コーディングに疲れたら息抜きにレビューしてるよ ・Pull Request が出たタイミングですぐにレビューしてるよ Q. ど タイミングでレビューしてる？ Q. レビューする前 下準備 ？ Pull Requests に関わるノウハウ

Slide 78

Slide 78 text

78 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 ・Pull Request 処理を追う で なく、 Pull Request によって達成したいことを考え他 アプローチが良さそうなら思い切って提案 ・人間が見るべきポイントをしっかり集中して見てみる、よく起きそうな間違いをまず見る 　→ 仕様 穴、セキュリティ /法的に大丈夫か、負債になりそうなところ、設計的にまずいところ、計算量 /レイテンシ的に厳しいところ 　→ なかなか人間 目で バグ 見つかりません！高品質なコード 高品質なテストから ・レビューに時間がかかる時点で PR 内容 理解が難しい で、理解するため コメントをしたり、話して教えてもらったりする ・レビュー 目的 Pull Request 内容 認識を合わせることだと意識する 　→ 全てを理解したり不具合を見つけようなど気負いすぎないようにするし、バグとか 見つけたらラッキーぐらいで考える ・議論しやすいけれど本質的で ない話 避ける (好み 問題だな〜という指摘をするかどうか 毎度悩む ...) ・Google's Code Review Guidelines に従う 人によって様々な で自分に合った「レビュー習慣」を身につけよう 入社3年目 先輩たち or 各部署チーム 工夫紹介 タイムマネジメント・取り組み方 不安 「レビューしたいが、自分 タスクで手一杯です 時間をどうやって管理したらいい かコツが掴めないです」 「レビュー 仕方を学んだことがない で どうやっていい か、どこから手をつけていい か…」 Q. レビューでみるところ・議論するべきところ ？ Pull Requests に関わるノウハウ

Slide 79

Slide 79 text

79 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 そもそもある程度、合意が取 れてる状況でレビューに持ち 込めてるかも (slackとかで進捗あげたり ) ・感謝 気持ちを忘れず、常に礼儀正しく真摯に対応し、レビュアーが自分 ために時間を 　割いてくれているありがたみを常に感じる ・人格攻撃 されていないとチームを信頼して会話する、気持ちを強く持つ ・返事に困った時でもとりあえずリアクションを付ける ・レビュー 相互 ため も な で、自分が納得するまで意味を理解してちゃんと議論しようと　する姿勢で いるようにしている ・レビューに なるべく早く返信する ・好みっぽい議論に できるだけ時間を使わず、影響度が大きいところに時間を使う ・レビュアー 意図や指摘内容をしっかりと理解し、次また同じ指摘を貰わないようにする ・再レビューしてもらう前に 2回ぐらいちゃんと見直し、楽観的にならない ・レビューコメントをもらって修正を加えたら、 commit hash をつけてコメントで返信する → コメントと変更を1対1にする(レビュワーに変更をわかりやすく伝える ) ・話がまとまらなさそうな時 直接会話して後からコメントでまとめを書く Google's Code Review Guidelines に従う Q. 開発効率を上げるために ？ Q. 気持ち 持ち方・コミュニケーション方法 ？ Pull Requests に関わるノウハウ

Slide 80

Slide 80 text

80 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 そもそもある程度、合意が取 れてる状況でレビューに持ち 込めてるかも (slackとかで進捗あげたり ) ・感謝 気持ちを忘れず、常に礼儀正しく真摯に対応し、レビュアーが自分 ために時間を 　割いてくれているありがたみを常に感じる ・人格攻撃 されていないとチームを信頼して会話する、気持ちを強く持つ ・返事に困った時でもとりあえずリアクションを付ける ・レビュー 相互 ため も な で、自分が納得するまで意味を理解してちゃんと議論しようと　する姿勢で いるようにしている ・レビューに なるべく早く返信する ・好みっぽい議論に できるだけ時間を使わず、影響度が大きいところに時間を使う ・レビュアー 意図や指摘内容をしっかりと理解し、次また同じ指摘を貰わないようにする ・再レビューしてもらう前に 2回ぐらいちゃんと見直し、楽観的にならない ・レビューコメントをもらって修正を加えたら、 commit hash をつけてコメントで返信する → コメントと変更を1対1にする(レビュワーに変更をわかりやすく伝える ) ・話がまとまらなさそうな時 直接会話して後からコメントでまとめを書く Google's Code Review Guidelines に従う Q. 開発効率を上げるために ？ Q. 気持ち 持ち方・コミュニケーション方法 ？ Pull Requests に関わるノウハウ

Slide 81

Slide 81 text

81 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. (レビューする) レビューコメント対応 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 そもそもある程度、合意が取 れてる状況でレビューに持ち 込めてるかも (slackとかで進捗あげたり ) ・感謝 気持ちを忘れず、常に礼儀正しく真摯に対応し、レビュアーが自分 ために時間を 　割いてくれているありがたみを常に感じる ・人格攻撃 されていないとチームを信頼して会話する、気持ちを強く持つ ・返事に困った時でもとりあえずリアクションを付ける ・レビュー 相互 ため も な で、自分が納得するまで意味を理解してちゃんと議論しようと　する姿勢で いるようにしている ・レビューに なるべく早く返信する ・好みっぽい議論に できるだけ時間を使わず、影響度が大きいところに時間を使う ・レビュアー 意図や指摘内容をしっかりと理解し、次また同じ指摘を貰わないようにする ・再レビューしてもらう前に 2回ぐらいちゃんと見直し、楽観的にならない ・レビューコメントをもらって修正を加えたら、 commit hash をつけてコメントで返信する → コメントと変更を1対1にする(レビュワーに変更をわかりやすく伝える ) ・話がまとまらなさそうな時 直接会話して後からコメントでまとめを書く Google's Code Review Guidelines に従う Q. 開発効率を上げるために ？ Q. 気持ち 持ち方・コミュニケーション方法 ？ Pull Requests に関わるノウハウ

Slide 82

Slide 82 text

82 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. レビューコメント対応 (レビューする) 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 1 Approve で merge OK ・原則 2 Approve 以上、0 Request Changes で merge OK ・アプリコード差分 Pull Request 作者以外が merge する ・それ以外だとセルフ merge OK ・etc… Q. merge 条件がある？ 退勤後 できるだけ merge や release をしないよ → もし merge や release 後にバグ出た時、人がたくさんいる方がそ 後 対処が安心 すぐに release！そして エラーが出ていないか 監視をするよ merge 後 すぐに branch を消すか、 設定で merge 後に自動的に branch が消してるよ → 他 人が間違って古い branch を使用する を防ぐ Q. merge タイミングがある？ Q. merge 後 ルールがある？ Pull Requests に関わるノウハウ

Slide 83

Slide 83 text

83 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. レビューコメント対応 (レビューする) 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 1 Approve で merge OK ・原則 2 Approve 以上、0 Request Changes で merge OK ・アプリコード差分 Pull Request 作者以外が merge する ・それ以外だとセルフ merge OK ・etc… Q. merge 条件がある？ 退勤後 できるだけ merge や release をしないよ → もし merge や release 後にバグ出た時、人がたくさんいる方がそ 後 対処が安心 すぐに release！そして エラーが出ていないか 監視をするよ merge 後 すぐに branch を消すか、 設定で merge 後に自動的に branch が消してるよ → 他 人が間違って古い branch を使用する を防ぐ Q. merge タイミングがある？ Q. merge 後 ルールがある？ Pull Requests に関わるノウハウ

Slide 84

Slide 84 text

84 ©MIXI GitHub Flow 1. branch 作成 2. 変更追加 (commit 作成) 3. Pull Request 作成 4. レビューコメント対応 (レビューする) 5. Pull Request merge 6. branch 削除 入社3年目 先輩たち or 各部署チーム 工夫紹介 1 Approve で merge OK ・原則 2 Approve 以上、0 Request Changes で merge OK ・アプリコード差分 Pull Request 作者以外が merge する ・それ以外だとセルフ merge OK ・etc… Q. merge 条件がある？ 退勤後 できるだけ merge や release をしないよ → もし merge や release 後にバグ出た時、人がたくさんいる方がそ 後 対処が安心 すぐに release！そして エラーが出ていないか 監視をするよ merge 後 すぐに branch を消すか、 設定で merge 後に自動的に branch が消してるよ → 他 人が間違って古い branch を使用する を防ぐ Q. merge タイミングがある？ Q. merge 後 ルールがある？ Pull Requests に関わるノウハウ

Slide 85

Slide 85 text

85 ©MIXI Pull Requests に関わるノウハウ 入社3年目 先輩たち or 各部署チーム 工夫紹介 モンストサーバ PR ... 特に branch 命名規則や テンプレートなどなく基本自由 1案件1機能 機能自体が大きくなりがち な で、Git Flow で説明した 「feature から feature を切る」テク を多用している → 前PR(向き先PR)があること 　を必ず明記 タイトル： 「いつまでに merge しないといけな い か、ど バージョン案件な か」を必ず明記 → 一部半自動化している description： 関連するリンクを必ず紐付ける

Slide 86

Slide 86 text

86 ©MIXI 入社3年目 先輩たち or 各部署チーム 工夫紹介 CI / CD： ・機械的にチェックできる部分 CIに任せる ・テストカバレッジを出力し、テスト 記載漏れに 　気づけるようにしている ・CI が通れ Pull Request を自動で merge する ・API と DB スキーマ間 前方互換性チェック ・workflow_dispatch で deploy (migration) する etc… Issues： 2ヶ月以上更新がない Issue に Stale ラベルがつき、さらに 2週間更新がない 場合に自動でクローズし、 Issue 放置を予防 etc… Pull Requests： ・workflow_dispatch で Release 用 Pull Request を自動生成 ・差分 量に応じて xs, s,m,l ラベルを自動付与 ・Pull Request merge 期日を半自動的にタイトルへ追記 ・Pull Request 作成者を Assignee として自動アサイン ・フォーマット修正 etc… リリースノート：workflow_dispatch で自動生成 etc… Actions に関わるノウハウ

Slide 87

Slide 87 text

87 ©MIXI 入社3年目 先輩たち or 各部署チーム 工夫紹介 CI / CD： ・機械的にチェックできる部分 CIに任せる ・テストカバレッジを出力し、テスト 記載漏れに 　気づけるようにしている ・CI が通れ Pull Request を自動で merge する ・API と DB スキーマ間 前方互換性チェック ・workflow_dispatch で deploy (migration) する etc… Issues： 2ヶ月以上更新がない Issue に Stale ラベルがつき、さらに 2週間更新がない 場合に自動でクローズし、 Issue 放置を予防 etc… Pull Requests： ・workflow_dispatch で Release 用 Pull Request を自動生成 ・差分 量に応じて xs, s,m,l ラベルを自動付与 ・Pull Request merge 期日を半自動的にタイトルへ追記 ・Pull Request 作成者を Assignee として自動アサイン ・フォーマット修正 etc… リリースノート：workflow_dispatch で自動生成 etc… Actions に関わるノウハウ

Slide 88

Slide 88 text

88 ©MIXI 入社3年目 先輩たち or 各部署チーム 工夫紹介 CI / CD： ・機械的にチェックできる部分 CIに任せる ・テストカバレッジを出力し、テスト 記載漏れに 　気づけるようにしている ・CI が通れ Pull Request を自動で merge する ・API と DB スキーマ間 前方互換性チェック ・workflow_dispatch で deploy (migration) する etc… Issues： 2ヶ月以上更新がない Issue に Stale ラベルがつき、さらに 2週間更新がない 場合に自動でクローズし、 Issue 放置を予防 etc… Pull Requests： ・workflow_dispatch で Release 用 Pull Request を自動生成 ・差分 量に応じて xs, s,m,l ラベルを自動付与 ・Pull Request merge 期日を半自動的にタイトルへ追記 ・Pull Request 作成者を Assignee として自動アサイン ・フォーマット修正 etc… リリースノート：workflow_dispatch で自動生成 etc… Actions に関わるノウハウ

Slide 89

Slide 89 text

89 ©MIXI 入社3年目 先輩たち or 各部署チーム 工夫紹介 CI / CD： ・機械的にチェックできる部分 CIに任せる ・テストカバレッジを出力し、テスト 記載漏れに 　気づけるようにしている ・CI が通れ Pull Request を自動で merge する ・API と DB スキーマ間 前方互換性チェック ・workflow_dispatch で deploy (migration) する etc… Issues： 2ヶ月以上更新がない Issue に Stale ラベルがつき、さらに 2週間更新がない 場合に自動でクローズし、 Issue 放置を予防 etc… Pull Requests： ・workflow_dispatch で Release 用 Pull Request を自動生成 ・差分 量に応じて xs, s,m,l ラベルを自動付与 ・Pull Request merge 期日を半自動的にタイトルへ追記 ・Pull Request 作成者を Assignee として自動アサイン ・フォーマット修正 etc… リリースノート：workflow_dispatch で自動生成 etc… Actions に関わるノウハウ

Slide 90

Slide 90 text

90 ©MIXI ● Code Rabbit (AIにレビューしてもらう) や ● GitHub Copilot (AIにコード書いてもらう) もある 自分で飼ってる AI お世話 自分でしよう NG例：GitHub Copilot コードそ まま出して、 Code Rabbit に指摘されたり... ● 全社で GHEC(GitHub Enterprise Cloud) 導入を推進している ● GitHub Actions とか Git LFS(Git Large File Storage) (GitHub で 大きいファイルを扱う )とか 使えるが、たくさん使うなら CTO にまず相談する ● GitHub API から FourKeys 計測したり、 FourKeys… DevOps Research and Assessment(DORA) 研究で確立されたソフトウェア開発チーム パフォーマンスを示す 4つ 指標 1. デプロイ 頻度：組織による正常な本番環境へ リリース 頻度 2. 変更 リードタイム：commit から本番環境稼働まで 所要時間 3. 変更障害率：デプロイが原因で本番環境で障害が発生する割合 (%) 4. サービス復元時間：組織が本番環境で 障害から回復する にかかる時間 そ 他 GitHub に関するノウハウ GitHub で 作業ややりとりなどをチームメンバー全員が目に付くところ (弊社 場合 Slack) に流して、 他 メンバーも議論に参加できるようにしているよ GitHub 通知を受け取れるようにしたり自分 GitHub アカウント名でメンションされるようにしておくといいよ

Slide 91

Slide 91 text

91 ©MIXI ● Code Rabbit (AIにレビューしてもらう) や ● GitHub Copilot (AIにコード書いてもらう) もある 自分で飼ってる AI お世話 自分でしよう NG例：GitHub Copilot コードそ まま出して、 Code Rabbit に指摘されたり... ● 全社で GHEC(GitHub Enterprise Cloud) 導入を推進している ● GitHub Actions とか Git LFS(Git Large File Storage) (GitHub で 大きいファイルを扱う )とか 使えるが、たくさん使うなら CTO にまず相談する ● GitHub API から FourKeys 計測したり、 FourKeys… DevOps Research and Assessment(DORA) 研究で確立されたソフトウェア開発チーム パフォーマンスを示す 4つ 指標 1. デプロイ 頻度：組織による正常な本番環境へ リリース 頻度 2. 変更 リードタイム：commit から本番環境稼働まで 所要時間 3. 変更障害率：デプロイが原因で本番環境で障害が発生する割合 (%) 4. サービス復元時間：組織が本番環境で 障害から回復する にかかる時間 そ 他 GitHub に関するノウハウ GitHub で 作業ややりとりなどをチームメンバー全員が目に付くところ (弊社 場合 Slack) に流して、 他 メンバーも議論に参加できるようにしているよ GitHub 通知を受け取れるようにしたり自分 GitHub アカウント名でメンションされるようにしておくといいよ

Slide 92

Slide 92 text

92 ©MIXI ● Code Rabbit (AIにレビューしてもらう) や ● GitHub Copilot (AIにコード書いてもらう) もある 自分で飼ってる AI お世話 自分でしよう NG例：GitHub Copilot コードそ まま出して、 Code Rabbit に指摘されたり... ● 全社で GHEC(GitHub Enterprise Cloud) 導入を推進している ● GitHub Actions とか Git LFS(Git Large File Storage) (GitHub で 大きいファイルを扱う )とか 使えるが、たくさん使うなら CTO にまず相談する ● GitHub API から FourKeys 計測したり、 FourKeys… DevOps Research and Assessment(DORA) 研究で確立されたソフトウェア開発チーム パフォーマンスを示す 4つ 指標 1. デプロイ 頻度：組織による正常な本番環境へ リリース 頻度 2. 変更 リードタイム：commit から本番環境稼働まで 所要時間 3. 変更障害率：デプロイが原因で本番環境で障害が発生する割合 (%) 4. サービス復元時間：組織が本番環境で 障害から回復する にかかる時間 そ 他 GitHub に関するノウハウ GitHub で 作業ややりとりなどをチームメンバー全員が目に付くところ (弊社 場合 Slack) に流して、 他 メンバーも議論に参加できるようにしているよ GitHub 通知を受け取れるようにしたり自分 GitHub アカウント名でメンションされるようにしておくといいよ

Slide 93

Slide 93 text

93 ©MIXI ● Code Rabbit (AIにレビューしてもらう) や ● GitHub Copilot (AIにコード書いてもらう) もある 自分で飼ってる AI お世話 自分でしよう NG例：GitHub Copilot コードそ まま出して、 Code Rabbit に指摘されたり... ● 全社で GHEC(GitHub Enterprise Cloud) 導入を推進している ● GitHub Actions とか Git LFS(Git Large File Storage) (GitHub で 大きいファイルを扱う )とか 使えるが、たくさん使うなら CTO にまず相談する ● GitHub API から FourKeys 計測したり、 FourKeys… DevOps Research and Assessment(DORA) 研究で確立されたソフトウェア開発チーム パフォーマンスを示す 4つ 指標 1. デプロイ 頻度：組織による正常な本番環境へ リリース 頻度 2. 変更 リードタイム：commit から本番環境稼働まで 所要時間 3. 変更障害率：デプロイが原因で本番環境で障害が発生する割合 (%) 4. サービス復元時間：組織が本番環境で 障害から回復する にかかる時間 そ 他 GitHub に関するノウハウ GitHub で 作業ややりとりなどをチームメンバー全員が目に付くところ (弊社 場合 Slack) に流して、 他 メンバーも議論に参加できるようにしているよ GitHub 通知を受け取れるようにしたり自分 GitHub アカウント名でメンションされるようにしておくといいよ

Slide 94

Slide 94 text

©MIXI まとめ

Slide 95

Slide 95 text

95 ©MIXI まとめ どこでも通用するチーム開発 基礎を学 ました。 ・Git を用いたチーム開発 ノウハウ 　→ Git 誕生秘話 　→ Git 特徴 　→ Git branch 戦略 (Git flow について) ・GitHub 機能 ・GitHub を用いたチーム開発 ノウハウ 　→ チーム開発に大切なこと(HRT, 気遣い) 　→ 各部署・各チーム、先輩達 工夫・ノウハウ紹介 『気遣い』ができるエンジニアになりましょう！

Slide 96

Slide 96 text

96 ©MIXI 入社3年目 先輩達から新卒 皆さんへメッセージ 2人チームな で、 チームメンバー（レビュアー）が読みやすい共通言語や使いやすいツールで書く が 一番効率いいよ って思う で相手に合わせてます わりかし git 使い方って人それぞれで癖ある で、こ 人 こんな感じで使うなぁとか、言い回し 癖とか意識すると良いかもしれないです GitHub お作法 OSS などでやりとりされている を見る が参考になると思う でもチームに それぞれ 文化があると思う でそれと上手く折り合いをつける が大事 テンプレート的にやる で なく、コミュニケーションしている相手・チームを 意識した開発ができるといいなと思う レビューをする (人 コードを読む) が一番 勉強になります レビュー 結構勉強になる ルールがあまり決まってない場合 他 人 Pull Request や Issue 書き方を見て、雰囲気で合わせるといいかも レビュー チェックより 情報共有だと思ってる ぺーぺー 立場でレビュー していく しんどいけど 大事な でがん ろう ほんとにチームによって文化が違うと思う で、臨機応変にいけるといい レビューについて メッセージ！ レビューって大事！

Slide 97

Slide 97 text

©MIXI