こんにちは、みなみです。
わたしはふだんSEの仕事をしており、先日ひさしぶりにソースコードレビューを行いました。
ソースコードレビューとは?
他の人が書いたプログラムコード(ソース)を読み、まちがいをチェックすることです。
ここ数年、めっきり自分でコードを書くことはなくなりましたが、一応、わたしも昔(Web1.0の時代)は書いていたので、今でも頑張ればできなくはありません。(笑)
ひさしぶりにソースコードレビューをして思ったことは「めちゃめちゃ大事」だということ。
開発段階でしっかりとチェックすれば、後のテスト工程がだいぶラクになりますから。。
コスト削減になるし、品質も格段にあがります。
もちろん、コードを書く前の共通認識や日ごろのコミュニケーションのほうが大事です。
が、いくら綿密に共通認識をとったとしても人間はまちがえる生きものですから。。
ソースコードレビューをおろそかにしてはいけません。
レビューしていて、おもしろいと思ったことは、プログラマーの意識がなんとなくわかること。(笑)
プログラムコードは、れっきとした「言語」ですからね。
ある程度、裏の背景を読み取ることはできます。
などなど。。
プログラムコードには性格がよく表れます。(笑)
レビューすることで、それが自分へのフィードバックにもなります。
たとえば。。
などなど。。
その人がどういうタイプの人間なのか、なんとなくわかるようになるので、つぎからの接し方の参考になります。
さらにレビュー結果を本人にフィードバックすれば、それはそれで大きな学びになるでしょう。
レビューって教育的な要素を含む重要なパートです。
あとこれは、あくまでもわたしの主観ですが。。
ソースコードビューをしっかりやってるプロジェクトって少ない気がしています。
なぜなら、手を抜こうと思えばいくらでもできるからです。(笑)
レビュアーがどこまでちゃんとコードを読むのか?
その基準を具体的にお客さんと合意してるプロジェクトなんてほとんどないでしょう。
レビューはテスト工程とはちがいエビデンス(証拠)をとらないので、いくらでもごまかせます。(笑)
そして、後のテスト工程で問題が発覚し、コストが膨らむことはけっこうあります。(汗)
ソースコードのレビュアーは、実装面(コードの書き方)と設計面(仕様要件)の両方を把握してる必要があると思っています。
結構やりがちなのは、実装面の共通ルール的なところ(コーディング規約など)だけをレビューし、済ませてしまうことです。
もちろん、それも大事ですけど。。
わたしは、設計面の観点を無視したソースコードレビューの効果は薄いと思っています。
プログラマーは意思疎通が苦手な人が多いので(笑)ちゃんとレビューしたほうがいいです。
「言葉」で確認するよりも、実際の「ソース」をみたほうが早いし、確実です。
まさに真実はソース(源泉)にある! ということですね。(笑)
というわけで、ソースコードレビューは大事だと思うお話でした。
最後まで読んでくださり、ありがとうございました。
↓ ランキング参加しています。よろしければポチっとお願いいたします。
にほんブログ村