🎉

コードレビューは通らない

2023/11/19に公開

こんにちは、さとうです!

先日、こんな記事を書きました。
コードレビューしてみよう!

レビューをした結果、すべての行に指摘が入り、更には設計ごと変更する、という結末を迎えてしまいました。
この例は極端に思えるかもしれませんが、似たようなことが実はよく発生します。

コードレビューを通る人は高度人材

よく指摘が入る部分を並べてみました。

  • テストコードがない・足りない
  • テストカバレッジが低すぎる
  • Value Objectを使っていない
    • 最大値の設定をしていない
    • 基本データ型をそのまま使っている
  • ミュータブルなオブジェクトを作っている
  • 可視性が広すぎる
  • 循環依存が発生している
  • ドメインロジックがドメイン層以外に漏れ出している

(これらすべてを人間がレビューする必要はありません。LinterなどのツールをCIに組み込めば、自動で検査してくれるものもあります。)

さて、これらすべてをクリアできる基準のコードを書ける人はどれくらいいるでしょうか?

このレビューを素通りできる人は、相当レベルが高いと考えられます。
このような、コードレビューの要求値が高い、という問題をどうすれば解決できるでしょうか。

モブプロを実践する(三人寄れば文殊の知恵)

もしあなたが初心者で、ひとりでコードを書いた場合、すべての行に指摘が入る可能性があります。

すると、あなたはこのように思うはずです。

  • 「一生懸命コードを書いたのに、すべて上書きされてしまう」
  • 「レビューされた部分が多すぎて、対応しきれない」
  • 「どうせすべて書き直すので、自分がコードを書く意味がない」

これではモチベーションが下がりますし、何より学びを得られていません。
学びの最適化をするためには、この状況は改善しなければなりません。

これを達成するために、複数人でコードを書くようにしましょう
また、モブプロにはシニアエンジニアを呼ぶようにします。

より素早くフィードバックを得ながら、コードを書くことによって、先ほどの問題を軽減することができます。

品質は捨てられない

スピードを確保するために、コードレビューの要求値を下げることで対応しようとしてしまうことがありますが、これは間違いです。
なぜなら、「品質を捨てたらスピードが確保できないから」です。

詳細はこちらをご参照ください。
質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition

結論

  • モブプロをしよう!
  • 品質は捨てられないよ!

終わりに

ソフトウェアは現代において欠かせない存在になっています。
ソフトウェアエンジニアに求められるレベルは非常に高いですが、それをクリアした上で、私たちは「規律、基準、倫理」を守らなければいけません。

参考資料

質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition

Clean Craftsmanship 規律、基準、倫理

継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣

Discussion