Slide 1
Slide 1 text
レビュー、キライ、...、
そして、今。
Recustomer株式会社 misato maeda
Slide 2
Slide 2 text
⾃⼰紹介
事業会社のマーケティング⽀援、制作部⾨
→受託会社のエンジニア
→Recustomer株式会社のエンジニア
Slide 3
Slide 3 text
突然ですが
Slide 4
Slide 4 text
私はレビューがキライです
Slide 5
Slide 5 text
● 実装の背景が不明
● 設計思想が不明
● コードが難しすぎて読めん
● ⼈間関係が怖い
● 採点してる/されている感覚
Slide 6
Slide 6 text
PRとの悲しい思い出
→ No Description の世界
Slide 7
Slide 7 text
PRとの悲しい思い出
→ 実装背景不明 の世界
Slide 8
Slide 8 text
さて、私が所属している
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
受賞してしまうくらい
開発スピードが
速いスタートアップ
Slide 12
Slide 12 text
ではレビューは雑なのか？
Slide 13
Slide 13 text
ではレビューは雑なのか？
いや、全然。
むしろ、めちゃくちゃ丁寧だったりします。
Slide 14
Slide 14 text
レビュー意識の⾼い会社
レビューされてないPRを
slackで通知する
1⽇に数回、こんな通知が届きます
Slide 15
Slide 15 text
そんなRecustomerの
取り組み
Slide 16
Slide 16 text
設計思想の統⼀
Slide 17
Slide 17 text
Recustomerの設計思想
DDD +
Hexagonal Architecture
を採⽤
Slide 18
Slide 18 text
上位モジュールが下位モジュールに
直接依存せず、抽象(インターフェース)に依存
● 密結合化が阻⽌される
● テスト容易性が向上する
Slide 19
Slide 19 text
各モジュールが単⼀の責務に集中
● 命名の議論が減る
● 過度な共通化が避けられる
Slide 20
Slide 20 text
全員が同じ設計思想のもとにコーディング
だから、
誰が書いても⼤きく揺れない統⼀されたコードになる
Slide 21
Slide 21 text
社内で「良いルール」の
共有
Slide 22
Slide 22 text
PythonCodingRulesを全員で作る
全員のapproveを経て
ルールの改訂を実施
Slide 23
Slide 23 text
PythonCodingRulesを全員で作る
全員のapproveを経て
ルールの改訂を実施
↓
AIフレンドリー
Slide 24
Slide 24 text
PRの細分化
Slide 25
Slide 25 text
責務の層ごとに分ける
責務の層ごとに分割した
PRを作成
Slide 26
Slide 26 text
1つの PR に⽬的を詰め込まない
→ PRの⽬的と本筋がズレる変更をあえて別PRに分けて対応する
Slide 27
Slide 27 text
実装前の認識合わせ
Slide 28
Slide 28 text
プランニング
→ 何かを達成した時に「誰がやった」ではなくて「チームで達成し
た」を⽬指したい
Slide 29
Slide 29 text
ドメインモデルレビュー会
→ 要件について共有しつつ、ドメインモデルレビューで⼿戻りを減
らす
Slide 30
Slide 30 text
テーブルレビュー会
明確な答えがない中で、
全員で考える⼀番良い設計
を共有する
Slide 31
Slide 31 text
Descriptionのフォーマット
Slide 32
Slide 32 text
載せることは最低限、シンプルに、わかりやすく
● バックログリンク
● 変更の意図‧経緯
● 変更の概要
● (UIの場合) スクリーンショットなど
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
...、(そう⾔われても)
Slide 35
Slide 35 text
どうレビューしていいか
わからない
Slide 36
Slide 36 text
着眼点を絞ってレビューする
Slide 37
Slide 37 text
ここだけ⾒ました！とレビューする
● 関数や変数の命名は動作を表現できているか
● 1つの関数内でさらに複数の処理を⾏うスーパー関数がで
きていないか
● エラーハンドリングが適切か
● 型定義が適切なのか
Slide 38
Slide 38 text
そして、
Slide 39
Slide 39 text
⼀番意識したい、
⼼理的安全性
Slide 40
Slide 40 text
質問ベースのコメント
→ お気持ち表明もありつつ、議論welcomeな⾵⼟
Slide 41
Slide 41 text
実装、レビュー、ありがとうございます！の⽂化
Slide 42
Slide 42 text
CTOの⾔葉
Slide 43
Slide 43 text
コードレビューは
「⽂化をつくるためのもの」
Slide 44
Slide 44 text
● 「LGTMボット」をつくらない
● レビューは考え⽅を共有する場
● 判断の理由をレビューに残す
→ それがチームの⽂化になる
Slide 45
Slide 45 text
Recustomerでは
このようにしてレビュー⽂化
を活発化
させてきました
Slide 46
Slide 46 text
そんな会社で過ごしてみて、
今。
Slide 47
Slide 47 text
コードレビュー
Slide 48
Slide 48 text
そんなにキライでも
ないような。