チームの認識を合わせる
チーム内の、Aさんと、Bさんの、それぞれの「理想」が合っていると円滑に事が進む
より良いものを作れる、より良い開発者体験を享受できる
「俺にとっての最高のコード」を他者が書いてくれれば最高
逆もまた然り
どういう問題が起きるのか
デザイナとエンジニアの認識の差異
デザイナが作ったカンプを、何のコミュニケーションもなくエンジニアが実装すると、思っていたものと異なるものができることが多々ある
例
ここって動くんだ
ここって文字数増えたら折返しじゃなくて、「...」と省略するんだ
データが空の時のデザインないじゃん
etc.
デザインカンプだけ見るとわからない点も多々ある
そこを推測するなり、話して聞くなりして認識の差異を埋めないとコレジャナイものができる
できてから気づく
エンジニア同士で起きる認識の差異
エンジニアの中でも何を大事にするのかや、どういう知識を持ち合わせているかで認識が異なる
例
型やテストって当然書くよね
commit messageって普通わかりやすく書くよね
関数って普通小さく作るよね
etc.
認識が合っていないと「なんでこんな分かりづらい書き方するんだ？」になる
実は、それは時間がなかったから妥協したのかも知れないし、何も考えずに書いたのかも知れない
こういう問題は、細かに指摘したり、勝手に直したりすることで、問題自体は解決できる
でも、それが積み重なると時間効率が悪いし、単純にヘイトが溜まる
チーム内の、Aさんと、Bさんの、それぞれの「理想」が合っていると円滑に事が進む
理想とはなにか
ただし、これだけでは大きすぎるので、更に細分化が必要
各人の理想がある場合は、互いの理想の根拠をぶつけ合えばいい
何かしらの根拠があるはずで、優先度を付けたり、納得することで理想を近づけられる
各人の理想がない場合もある
Aさんが「悪いコードの例」を出しても、Bさんは「どこが悪いのかわからない」と感じる場合がある
この場合、Bさんは絶対にこれを改善することはできない
ここに問題があるよということに、そもそも気づかせる必要がある
ここはもう運用でカバーするしかない領域だと諦めて(?)いるmrsekut.icon 自動化できるならそうしたいが、できる気があまりしない
どうやって認識を合わせていくか
本の輪読などをして、それが提示する理想と、自分らの状況を鑑みて、自分らの理想を設定していく
話し合い
「これはクソだ」と雑談レベルで話せるのが理想的
細かい指摘と議論
指摘だけでは、「まあ言われたから直すか」になってしまう可能性がある
指摘された側の直すモチベーションが、「指摘されたから」になってしまうと問題は解決されていない 今後も同じ問題が生じ続ける
議論をして、理想をぶつけ合っていかないといけない
ただのコードレビューだけでは問題の解決にはならない