« 現場でSeleniumを使ってみた! | トップページ | Androidアプリの抜き打ち?コードレビュー »

「実践!、コードレビュー」の話

10月の定例会の際に、三文字さんしょっちゅうご紹介している名前ですが)から、顧客先で行われた「ソースコードレビューに関して」を発端として、三文字さん自身の経験や見解の話をしてくれました。

Pict2665
彼はアーキでありサブリーダーでもあり、一流のプログラマーでもあります

プロジェクト中で、レビュワーとしても多忙を極めた結果を踏まえたお話でした。

話の内容全体を下記に要約します。

そもそも「コードレビューとは・・・」
 クソコード(唐突に過激な表現で済みません...)をましなコードに直す!
 レビューしないとそもそもクソコードかどうかすら分からないので、先ずはレビューしましょう!

クソコードとは・・・
 「レビュー中に怒りの渦に叩き落されるコード」
 ・そもそも正しく動かない
   読んだ限り正しそうに見えない
 ・読めない!(読みにくい)
   コメントと実装が合ってない
   変数名や関数名が適当(名前が機能・意義付けを表していない、etc.)
   実装が不必要なほどに、やたら複雑
 ・要領が悪い
   冗長なコードがある
   関数化が適当じゃない
   言語の特性を殺している
   フレームワークの売り・特性を無視している
 ・意図が不明
   設計書と実装に乖離がある
   謎の計算式など

コードレビューはなるべく優秀なプログラマに見てもらうこと
 では優秀なプログラマとは・・・クソコードを書かない人
 一行一行について、背景にある論理を熱く語れる人!

レビューする上での要点
 ・レビューの観点を明確にする
   クソコードの廃止
   パフォーマンス
   セキュリティ
   (余り多くの観点を、同時にレビューしようとしない)
 ・自分のことは棚に上げる!
   遠慮はNG!!
   自分の悪い点も気付いたのであれば、自分の成長のチャンスと捉える寛容さが必要
 ・悪い点は論理的に説明する
   悪いという直勘は7割ほど当たるが、指摘される側を理解・納得させる必要がある
   以降に書くコードが改善されることが目的
 ・お手本になるコードを共有する
   初期ならチーム全員のディスカッションでも良いかも知れない
 ・小さい単位でレビューする
   レビュー自体が30分~1時間程度で終わる単位
   貯め込むと、レビューするのも、直すのも、直した結果を確認するのも大変になる
   時間が無いからいいかな...、とか「直せない」心理を防ぐ
 ・指摘は素直に聞く(聞いてもらう)
   なぜ指摘されたのかを理解・納得して対応する
 ・人格を攻撃しない
   「クソコードを憎んで人を憎まず!」
   今後のコミュニケーションや信頼関係に影響が出るので要注意(プラスにもマイナスにも)

この「コードレビュー」に関しては、先の記事(Seleniumでのテストコード)に付いても言えることですね。

テストコードは「正しい」という前提で動かしますから、テストコード自体のバグは継続的に引き継がれて行ってしまうことになります。
(実際に、このような例が現場でも見られたそうです)

無論の事ですが、レビューにもコストが掛かります
メリットとデメリット、納期、スキルのばらつき...。
様々な要素が有るので、通り一遍のレビューガイドラインを単純に、全員に・全コードに適用すれば良い!、という訳でもありません

この辺は、明示的なレビューガイドラインを共有し、全員が理解・納得していること
現実の運用に際しては、実態に応じて見直していく、その時々でベターな適用の仕方をしていくことも必要です。

さて!、定例会の最後に毎回・振り返りをしているのですが、
「クソコードをレビュー会を実際にやってみたい!」という声が上がりました。

Tryですね!!

「12月の定例会に合わせて準備し実行する」ことに、その場で決まっちゃいました!

毎度毎度で申し訳ないんですが、三文字さん、宜しくお願いしますっ!!


★クリック1つでブログランキングにご協力戴けます! m(_ _)m

|

« 現場でSeleniumを使ってみた! | トップページ | Androidアプリの抜き打ち?コードレビュー »

定例会、勉強会など」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「実践!、コードレビュー」の話:

« 現場でSeleniumを使ってみた! | トップページ | Androidアプリの抜き打ち?コードレビュー »