コードレビューで生じる開発遅延について

Question

いつもお世話になっております。

コードレビューについて書かせていただきます。

私はプログラミング能力が低いので、結構指摘を受けます。

でも、コードレビューって良い文化ですよね。
コードレビューのメリットって皆様もわかっているだろうし、
ネットにも色々あがっているのでここでは割愛します。

ただ、コードレビューって開発スケジュールの遅延を発生させませんか？
誤記や考慮漏れ、バグ等は遅延しても直すべきだと思いますが、
Aという方法で実装していたのに、Bという方法で実装すべきって言われた時。

上記ケースの場合、私はAとBの実装について、議論して、将来的にBの方が良いと判断された（判断した）場合は、遅延してでも修正します。
でも、この時点で規模にもよりますが、修正+レビューで、1日遅延出ますよね。

さらに、Bで実装し始めて、議論の時に見つからなかった問題が発生したり、余計に遅延が発生する時がありますよね。
こういう時ってみなさんは割り切ってますか？

補足ですが、
立場的にはSESなので、開発遅延＝能力低いと思われがちです。

Answer 1

指摘が重複してますが・・・

ただ、コードレビューって開発スケジュールの遅延を発生させませんか？

基本的な考え方としては、後工程でバグ対応するよりレビューでつぶしたほうが
全体的な開発スケジュールは短くなるはずです。
地味な話でいうと、テスト工程でバグでると障害管理表の起票とか対応確認、エビデンス取得とか
工数が多くかかりませんか？

そもそも、コードレビューは品質担保の一環なので、スケジュールとして見積もりに含めるべきです。
また、コスト削減やなんらかの意図があって見積もりに含めないのであれば、
本当にやらない。または、見積もりに含まれないのに実施すれば、遅延が発生するでしょう。

さらに、Bで実装し始めて、議論の時に見つからなかった問題が発生したり、余計に遅延が発生する時がありますよね。

こういう時ってみなさんは割り切ってますか？

実装方法が変わるような指摘をコードレビューでうけたことがないのですが・・・
実装の変更ではなく、設計の変更ではないですか？
であれば、設計（いわゆる詳細設計orプログラム設計）でのレビューが必要かもしれません。

問題の発生が、製造時であれば、レビューの指摘が不適切です。テスト時であれば、最初からテストの
見積もりに含めておけば問題ないと思います。

あとペアプロって、レビューが同時にできるので形式ばったレビューでなく、
ピックアップして実践してみるとよいかもしれません。

Comments

[Heidi]

回答ありがとうございます。
お礼大変おそくなり申し訳ありません。

ご指摘の通り、設計が影響しているかもしれないです。
設計は各自に任せられていて、チーム内で共有はしていません。
設計レビューをするのが未然に防ぐ方法の第一手段になりそうですね。

Answer 2

普通、スケジュールってリスクなどで20％～30％ほど余分に取っているはずですが、
スケジュール100％使い切らないといけないケースって見積段階でミスっていると思います。
なので、コードレビューでいくら指摘されても全体のスケジュールに対して遅延は起こりません。
全体のスケジュールに対して遅れが生じる場合は、
先にpgm_bakabonさんからアラートを上げて遅れる旨伝えましょう。
他の人がリカバリーに入ってくれるのが普通のチームです。

さらに、Bで実装し始めて、議論の時に見つからなかった問題が、、、

こういう問題を見つけれなかったレビュアーに問題があります。
何のためにレビューして指摘しているんだって話です。
ちゃんと機能設計してあればすぐ気づきます。

と、完全に他人に責任を押し付けてるのですが、
コードレビュー何回も受けているのであれば、
そんなに大きな修正の指摘をもらうことも少なくなってくるのではないしょうか。
プロフィール見させていただたところ7年目ということなので、
そろそろレビューする側の仕事もされると勉強になるかと思います。
レビューするというよりは色々な書き方があることを勉強できます。

Comments

[Heidi]

回答ありがとうございます。
お礼おそくなり申し訳ありません。

設計レビューをしていない影響が大きそうです。
設計レビューを設けて、影響のでかいレビュー指摘等が発生しないか経過を見てみようと思います。

Answer 3

ちょうど最近、コードレビューを長期に渡ってしなかった事例が、レビューする側の立場から「主観的」な記事として上がっていました。
後輩にレビューで突っ込みを入れていたらスパゲティができたでござるの巻

レビューで指摘される内容って、結局放置できるようなものは少ないので、できるだけ早めに潰して、全体タスクの見積もりにブレがないようにしたいっていうのが、マネジメント側の発想です。

Comments

[Heidi]

回答ありがとうございます。
記事拝見しました。
どちらかというと記事でいう「後輩」に近いことをやりがちなので、反面教師として気をつけたいと思います汗

Answer 4

@IT > 自分戦略研究所 >エンジニアライフ > Press Enter■
http://el.jibun.atmarkit.co.jp/pressenter/
’
お読みでなければ、息抜きにどうぞ。開発現場etc の種々、あるある物語。
’
「リーベルG さんの著作リスト」
飛田ショウマの憂鬱
高村ミスズの事件簿
ひいらぎ飾ろう
ハローサマー、グッドバイ
賢者の贈り物
罪と罰
高村ミスズ女史の事件簿
鼠と竜のゲーム
冷たい方程式
人形つかい
高慢と偏見

Comments

[Heidi]

回答ありがとうございます。
お礼おそくなり申し訳ありません。

この手の記事は読んだことがないので、時間見つけて読んでみたいと思います。