レビューイは、レビューアにレビューを依頼することで、レビューが開始される。3.遵守事項レビューでは、コード可読性や、コードの一貫性(個人技のようなコーディングスタイルではないこと)など、コーディング規約に基づく評価を行うこと。すべてのレビューにおいて、レビューアとレビューイは対等であり、常にコーディング規約と照らし合わせた上で、対象となるコードに向き合い議論を交わすこと。その議論は双方ともに客観的かつ論理的であること(感情・直感的な議論は避けること)。レビューアは、対象となるコードについて議論する際、可能な限りサンプルコードや疑似コード、有効な文献などを用いて評価すること。良いコードにはLGTM等にて評価するのが望ましい。4.禁止事項レビューアは、対象となるコードに対して感情的な評価をコメントしてはならない。レビューイは、レビューアの指摘に対して感情的な反論をコメントしてはならい。レビューアは、レビューイの説明を無視したり、合意のない状態でレビューを中断・放棄してはならない。「目的」には、前節の最初に書いた文章を、ほぼそのまま持ってきています。「用語」欄は案外重要で、この定義によって、書いている内容の表記ゆれを防ぎつつ、読み手全員に同じ意味を伝えることが可能になります。「遵守事項」には、コードレビューで絶対遵守すべき事柄を手短にまとめました。4行程度であれば、なんとか皆が読んでくれるでしょう。「禁止事項」には、コードレビューで絶対やってはいけない事柄を手短にまとめました。冷静なときに読めば、普通に理解できることだと思います。前節でも書いた通り、コードレビューのど真ん中で感情の渦に飲まれてしまった人にとって、ここに書かれたことはある意味「失われた知性」とも言えるでしょう。この規約は、弊社のLetro開発チーム全体に適用し、現在も運用中のコードレビュー規約となっています。実はさらにこの後ろに、コードレビューにおける評価基準を設けていますが、これは組織、プロダクト、チームなどで異なると思いますので、本記事では長くなってしまうこともあり、割愛いたします。運用できるサイズの、有意な規約を作ろう「仏作って魂入れず」ではありませんが、規約や規則というのは、往々にして「規約作って運用されず」という状態に至ることがあります。この原因の1つとしては、規約にすべてを詰め込んだ結果、誰にも読まれず、読まれても記憶されず、必要な場面でも長すぎるため参照する気持ちが失われる、といったことがあると考えています。私は以下の3点を、規約を作る際には十分に心がけるようにしています。絶対に必要なことだけ入れる(取捨選択)可能な限り理解しやすい言葉を選ぶ(ただし規約という書類の性質上、難しい場合もある)誰が読んでも誤解されにくい文章を構成する実は弊社はベトナムにも開発パートナーが多数在籍しています。そのため、上記の2.については「翻訳しやすい&誤訳されにくい日本語で作成する」という意図も含まれています。規約の作成を進めていくと、実際にはこの3点をすべて満たした文面の作成はかなり難しいと思います。一度ラフ案を作ったらチームメンバー(一部のメンバーでもよい)とミーティングを設定して、意見交換をしながら最終稿まで持っていくことをオススメします。以上、コードレビュー規約を制定する上での考慮点とともに、弊社Letro開発チームで実際に使用している規約の一部を抜粋しながら、ご紹介しました。次回は、このコードレビュー規約の運用面について文書化したものがご紹介できればと思います。最後までお読みいただき、ありがとうございました。みこやんプログラミングもサーバもフロント(チョトだけ)もインフラ(オンプレ中心)もwebもゲームも組み込みも幅広く何でも雑多にやってきた古株ですが、フルスタックではありません。好きなものはプログラミングと計算機科学。US私たち”アライドアーキテクツのエンジニア”は”世界をよりよく変えたい”という想いを強く持ちながらWebサービスを創っています。”日本発、世界的なWebサービスを創る”ことをエンジニアチームは本気で考え、毎日チャレンジしています。