Chapter 06

コード共有とレビュー

nobuhito
nobuhito
2022.03.06に更新

最近は Git というツールを中心にして、プログラムコードの共有とレビューしやすい環境が整っています。

https://backlog.com/ja/git-tutorial/

ただ、レビューに間してはみんなの前でダメ出しされる機会と捉えられ、人によってはあまり有用な場と感じられないことも多くあります。
そのため、レビューに間してはその目的について関わる人達で共有する必要があります。また、その目的を良い形で達成するためにフローについても考える必要があります。

共有とレビューの目的

いくつか考えられるレビューの目的で、一番大きいのは「提供するプログラムの品質担保」ということは理解しておきたいところです。その次の目的として、担当者以外も必要に応じて内容を確認できたり、メンテナンス出来たりというところになります。
「品質を担保」するということは「品質に悪い所があれば直す」ことになるます。もしここで「品質とはなにか」というところが共有されてないと、「ここまでするのか」という負の感情が芽生えてしまうことになってしまいます。

ソフトウェア品質を評価する指標には、以下の 6 つがあります。

https://www.softwarejobs.jp/media/000023
  1. 機能性
  2. 使用性
  3. 信頼性
  4. 効率性
  5. 保守性
  6. 移植性

このうち、1~4 についてはユーザーが実際に利用して確認するしか無いところもありますが、3~6 についてはレビューでも確認できる場合があります。

とくに、「信頼性」と「効率性」については開発経験が長くなればなるほど「コードの臭い」としてなんとなく分かって来ます。また、「保守性」や「移植性」に間しては、適切なコードの分割や命名が出来ているかを見れば分かってきます。

https://ja.wikipedia.org/wiki/コードの臭い

共有とレビューの方法

目的が分かったとしても、やっぱりレビューはダメ出しのような感じになってしまう場合が多々あります。
「それはなぜか」と考えてみると、やっぱりコードにダメなところが多いからです。ですが「なぜコードにダメなところが多いか」ということを考えてみると、ほとんどは経験が少ないからというところにたどり着くはずです。経験が少ないのでダメな部分があるのは、そもそも仕方ないところでもあるというところです。

では、そういう場合はどうしたらよいか。

コードレビューだからといって、特別なことをする必要はありません。報告書や稟議書を作成しているときと同じやりかたをすれば良いはずです。

多分、そういうものであれば回覧を始める前などに、上司から事前チェックしてもらうことでしょう。それと同じことをすれば、同じ様に物事が進むはずです。
個人リポジトリを作成してそのリポジトリだけを狭い範囲で共有し、コードが小さいうちから要所要所で確認してもらうということで、完成してから作り直しということを防ぐことも出来るようになります。