開発していると必ず行われるのがレビューですね。 しかし、そのレビューを上手にできてないところがありますね。 まず「指摘件数」を死に物狂いで管理しようとしている現場。 いや、品質の指標としてはいいんですよ、指摘件数とか記録しても。でも、レビュー前にレビュー対象物の作成方法において「如何にしたら指摘件数が増えないようにできるか」という議論もなく、単に指摘件数だけで品質管理するのはナンセンスもいいところですよね。こういう現場は、レビューによる指摘件数が少ないとレビューがちゃんとできてないなんて烙印を押すのです。 それから、これは今私がやらされてることなんですが、レビュー記録をつけるとき指摘事項の「分類」とやらを記載しなければならないことになっています。これは、簡単に言えばその指摘はケアレスミスを指摘したものなのか、それともレビューイの認識不足を指摘したものかなどの観点で記載するものです。 これは
彼は最も酷いレビューのいくつかの例を次のように挙げている。 コーディングを行った開発者を脅したり攻撃したりする魔女狩りレビュー 深刻な問題は放っておいて、記述方法やインデントについて注力する中括弧論争レビュー レビュアーが事前にコードを見ることがなく、また事前準備もない状態でレビューに臨む盲目レビュー コードの一部のみをレビュー対象とし大事な箇所が対象として除外されてしまう除外レビュー レビューを行うことが不可能である、またレビューをしたとしても効果のないくらいコードベースが大きくなってから行う紙の無駄使いレビュー プロジェクト管理上こなさなければならない形式的に実施するトークンレビュー 大多数がプロジェクトに関係なく開発者を威嚇するために存在するような多人数で実施するワールドレビュー InfoQ: デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー (少なくとも僕が経験した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
