コードレビューの「困った…」の解決方法 Part1『伝わるコードレビュー 開発チームの生産性を高める「上手な伝え方」の教科書』~実践編~ #ポエム – Qiita

プロジェクトには、一般的にルールがあります。しかし、コーディング規約などの細かいルールは意外と明文化されていなかったり、既存メンバーも言語化していなかったりするものです。これによって、余計なコミュニケーションが発生したり、イライラなどが溜まっていきます。

そのためにも、プロジェクトのルールはいつでも見れる場所に置いておくことが必要です。例えば、以下に記載しておくなどです。

• プロジェクト管理ツール（Github, Backlog, RedMineなど）のwiki
• README

上記のような開発メンバーが普段から意識しやすい場所にルールを明文化しておけば、新規メンバーにとってもルールをキャッチアップしやすくなります。

また、このようなルールを作成した場合、ルールを作ったままにするのではなく、メンテナンスを続けることが必要です。
さらに、ルールを作成するにあたって、気をつけたいアンチパターンがあります。

• 完成しないルール
  • 最初に全てをルール化しようとして書ききれず、頓挫してしまう
• 細かすぎるルール
  • 誰も厳密なチェックができず、そのうち形だけのルールになってしまう

上記のようにならないためにも、最初に始めるのは最小限のルールが良いです。最小限のルールから始めることで、メンバーの認識を深めやすくなっていきます。また、メンテナンスもしやすくなるため、メンテナンスサイクルの中でチームの文化を育てることができます。

↓メンテナンスサイクル↓

ポイントは以下です。

2. 自動化できるチェック項目をレビュアーが指摘している

if num.zero?
    # numが`0`の時の処理
elsif num > 0
    # numが`0`より大きい時の処理
else
    # numが`0`より小さい時の処理
end

fruits = ["apple", "banana", "cherry"]
index = 0

fruits.each do |fruit|
  puts "#{index}: #{fruit}"
  index += 1
end

#=> 0: apple
#=> 1: banana
#=> 2: cherry

fruits = ["apple", "banana", "cherry"]

fruits.each_with_index do |fruit, index|
  puts "#{index}: #{fruit}"
end