レビュー、キライ、…、そして、今。

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