社内でコードレビューのチェックリストを育てているよ

こんにちは、フロントエンドエンジニアの茶木です。

コードレビューする際のチェックリストを、知見を集めて社内メンバーで作成しています。

• レビューする際に確認すべき項目の指針になるもの
• レビューしたことのないメンバーが確認すべき項目がわかるドキュメント

上記2点についての Wiki で運用しながら育てていくチェックリストなので、今後も加筆が進んでいくはずです。今日はチェックリストの一部について紹介します。

構成

チェックリストは、以下の項目からなっています。
先頭4項目は、特定の言語やフレームワークに依存しない重要な項目で、最後の項目は特定の言語やフレームワークについて、先頭4項目を実現するためのアプローチについてまとめていっています。

• 正しく機能するか
• パフォーマンスが良いか
• 読みやすいか
• メンテしやすいか
• 言語・フレームワークごとの項目

正しく機能するか

言語やフレームワークに依存しない基本的なチェック項目です。大項目は「仕様と齟齬がないか」という点と「機能に不具合がないか」という点。後者は、既存機能に影響がないか、エッジケースも想定しているか、ユーザーが使いやすいか、という小項目にわかれます。

パフォーマンスが良好か

パフォーマンスは以下の項目がチェックリストになっています。

• 実行速度の観点を持って書かれているか
• 不要なアクセスがないか
• 非推奨機能や・古いライブラリを用いてないか

言語・フレームワークごとに、より具体的なのノウハウがあり、別項目としてまとめており、今後、知見が貯まってくると思います。

読みやすいか

「命名規則に従っているか」、「端的で意味のある名前をつけているか」、「意図が読み取れるかコードか」、「ファイルやスコープのサイズが大きすぎないか」、「不要なコメントがないか」など、多岐に渡っています。

メンテしやすいか

「作り込みすぎていないか」、「テストはあるか」が立項されています。後者はわかりやすいですが、前者は、どのような状態を作り込みすぎているか？といった観点で噛み砕いた加筆ができると良いと考えています。

言語・フレームワークごとの項目

JavaScript, TypeScript, React, HTML, CSS などの項目があります。ここでは JS系列のものを少し紹介します。

JavaScript / TypeScript

ネストが深くなりすぎないようにする工夫や、非同期関数の使い方、配列操作、型変換など、JS/TS 特有のテクニカルな記述があります。まだまだ追記されると思います。

React

特に、コンポーネントの扱いについて、多くの項目があります。コンポーネントを純粋に保っているかといった、重要ながらチェックリストで扱うには難しい課題も残っています。

おわりに

コードレビューはプロダクトの安定性・堅牢性を確保することに繋がります。社内メンバーでも得意分野がまちまちなので、ドキュメント化を進めることで技能の平準化ができると良いと考えます。また、ドキュメントを作って終わりではなく、うまく運用できているか、加筆しやすいドキュメントになっているかという観点も重要だと考えています。