設計レビューやソースレビューの意義や効率的な進め方に関して
背景として、属人的なプログラム実装や設計をフラットにしてレガシーな環境をレビューを行って何とか減らしていきたいという思いがあります。gitやチャットを導入して、WEBを介してある程度の情報量は共有出来ていると思っているのですが、チームで共有出来ているかというと感覚としては浸透していない印象です。
今まであまりレビュー文化がないプロジェクトばかりで知見や経験値不足の為質問させて頂きます。
何点か聞きたい事、意見を募りたい事があるので箇条書きにします。
主観やご自身の経験に即した意見でもぜひ参考にしたいので屈託のないご意見頂ければ大変うれしいです。
レビュー実施の意義
本来レビューとはより広域な視点や経験を持っている方からフィードバックをもらう為に実施するものだと勝手に思っています。少なからず内部的な設計は一番自分が網羅していると仮定して、メンバーにレビューを実施する意義とは何なのでしょうか?
仮に設計した内容の周知等が目的であるのであれば、作った資料やソースを確認頂いて疑問点等あれば個別でフィードバックしてもらうのが効率的だと思うのですが、一同に介し個人のレベルがバラバラの状態でレビューの時間を割く意義はあるのでしょうか?
具体的なレビューの進め方
一番苦労している所です。
ソースレビューに関しては、ソースを追って説明をしています。(ここの階層にパスを作って新たにこういったクラス群をまとめて格納しています云々。そのクラス・メソッドはこういう処理をしています云々)
この進め方に関しては、上述のようにコミット内容をプログラマ個々人が確認する様にすればOKなのではないか?というレベルです。設計レビューに関しても同様で作成した仕様書を説明して流すという時間をメンバーが一同に介して行っています。
設計レビューに関しては、事前に公開して回覧レビュー等を行ってはいますが非効率に思えてなりません。
成果物を公開してその説明をいちいち追いながらやるというやり方が正解なのでしょうか?
効率的・効果的なレビューに関する情報
自分でもWEB・書籍等探してはいるのですがやはり選定が難しいと感じています。
参考にした書籍や情報等あれば、是非教えて頂きたいです。
コードレビューに関わらず、領域が広いフローのレビューを対象にしたかったのでタグは関連しそうなものを追加させて頂きました。上記項目に関わらず、何かレビューを実施する・文化を定着させることで意見や感想等あれば(そもそもレビューをやめて、こういった手法をとればいい等)ぜひ参考にさせて頂きたいです。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/11 02:56
2017/04/11 03:37
2017/04/11 03:52