Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

Chatworkフロントエンドが品質を保つために行なっているモブレビューについてのお話

こんにちは!フロントエンド開発部の石山です!

フロントエンド開発部では、スケールしやすいアプリケーションを目指して日々改善を行なっています。

今回はコードの品質を高めるためにフロントエンドチームが行なっている、モブレビュー会を紹介します!

モブレビュー会とは

モブレビュー会は1つのPRをフロントエンドメンバー全員でレビューを行う場です。

ここではコードに対しての疑問点や改善点を絞り出すことに焦点を置いてレビューします。

モブレビュー会を始めたきっかけ

フロントエンド開発部では、メンバー間でアーキテクチャや知識を共有する目的でモブワークを行なっていました。

モブワークを行うにあたって、下記の問題点が浮かんできました。

  • 長考する時間が取りづらい
  • 拘束時間が長く、メンバー間で時間の都合をつけづらい
  • ノウハウ持ってる人ほど忙しい傾向があり必要な同期がとれない

そこで、既にマージされたPRを全員でレビューするという試みを行なったところ、「コストが高い割に知識を共有するための効率が良くない」などの問題点を改善しつつ、必要な知識の共有を進めることができました。

最初は一部のチームで始めましたが、「知識の共有になる」「レビュアーの練習にもなる」と評判が良い取り組みだったので、全体で行うことになりました。

モブレビュー会の流れ

  1. 事前にレビューの題材となるマージ済みのPRをピックアップする
  2. 題材のPRをレビューする (30分)
  3. コメントの確認・ディスカッションを行う

なぜマージ済みのPRをレビューするのか

モブレビュー会の特徴としては、マージ済みのPRをレビューする所だと思います。 以下の理由からマージ済みのPRをレビューするようにしています。

  • 通常のレビューではレビュアーも「リリースするかどうか」のプレッシャーが無意識にかかるため、PRマージ後にカジュアルにレビューをすることで、フラットな目線で意見を言いやすくなる
  • マージされているので動作確認も省けるため、フロントエンドメンバー全員の拘束時間を短くすることができる
  • 挙がった改善案をリファクタリングのチケットにすることで、改善につなげている

全員のコメント後、レビューコメントを司会者が一つずつ確認していき、コードに対する改善案のディスカッションになります。

また、今後に向けたアーキテクチャ方針共有やドメイン知識の共有を行うことができるため、局所的なコードの知見だけではなくアプリケーション全体の知見が溜まったりする副産物が多い場所になります。

レビューのコメントたった一つに対してでも、メンバーが納得できるまで10分以上議論することはザラにあります。チームメンバー全員が、プロダクト・コードをいかにより良いものにしていくかに対して時間を惜しまないという姿勢を持っています。

複数人で1つのPRをレビューするため、コメントや改善点が多くなります。 この際、コメントに対するメンバーが意識しているポイントがあると思っています。

レビューをするときに意識していること

チーム内で「これを意識しよう!」というようなことは無いのですが、僕が思うチーム内に浸透しているコードレビューのポイントをピックアップしてみました。

  • 人ではなくコードに対して言及する
  • 相手への疑問ではなく、自分への疑問のように「〜の方が良いのでしょうか?」のように質問にする
  • コーディングスキルを否定しない

実際のレビューコメント

  • 状態遷移が複雑で、複数の値が同時に変更されるので、状態遷移を整理してstateをuseStateでつくるのではなくuseReducerにしてあげれば、状態管理がすっきりすると思われます。(参考にしたコードを持ってきただけな気がしつつ...)
  • ここからJSXまでのコードが長いので、関連のある単位でファイル内で使うカスタムフックを定義してあげるとよさそう。
  • 呼び出し箇所でundefinedチェックをしてるので、いっそ初期値を返した方がいい
  • 未入力という値を用意してあげるのがいいかもしれない
  • useCallback使っているが、コンポーネント内部にあるので都度生成されそうな気がする。

普段のPRレビューに比べて人数が多いため比例してレビューコメントが増えてしまいます。

ですが上記のようなレビューコメント時の意識がチーム内に浸透しているため、レビューされる側は身構えることなくコメントと向き合うことができる環境だと思っています。

個人を批判するようなコメントがあるようなモブレビュー会だと、建設的なものではなく「全員でボコボコにされる公開処刑」のようなものになってしまうので気配りやチームの雰囲気づくりが重要です。 ※そのような事になったことは1度もありません!!!

モブレビュー会を始めて4ヶ月ほど経ちますが、1時間あるモブレビュー会の時間内に終わったレビュー会は少ないです。

これはレビュワー・レビューイが「コードの価値・品質を上げる」という目的を共有できているからかと思います。

モブレビューをやってみてよかったこと

モブレビューをやってみて生まれた副産物があります。

  • レビュー時に気付くことができなったポイントを見つけることができた
  • 他の人がレビューする際の観点を知ることができた
  • メンバーが持っていない知識・観点を全員に共有することができた

他フロントエンドメンバーの感想

  • 誰がなにを考えているのか思考がわかる
  • モブプロしなくてもここで同期的に知見が溜まる
  • モブだとその場で助言してもらって、なにも考えなくてもコード書けちゃうので、コード書く->指摘で学ぶができる
  • みんなの知見が広がった
  • 勉強になる。継続したい。

さいごに

モブレビューはレビューイだけでなく、レビュワーも学ぶことができるのでチーム全体の知見を溜めることができる良いディスカッションの場になるのだと思います。

日頃からメンバーお互いがリスペクトや思いやりを持って接しているからこそ、良いモブレビュー会を行うことができるのだと思います。

モブレビューをやってみてチームとコードにとって良かったところがたくさんありましたので、是非皆さんも取り入れてみてください!

また、フロントエンド開発部では宣言的 UIやアーキテクチャに関する「FPUI 研究ラジオ」を配信中です! 気になるかたは聞いてみてください!

chatwork.connpass.com

www.youtube.com