変なレビューにつきあわされる - イトウ アスカ blog
開発していると必ず行われるのがレビューですね。 しかし、そのレビューを上手にできてないところがありますね。 まず「指摘件数」を死に物狂いで管理しようとしている現場。 いや、品質の指標としてはいいんですよ、指摘件数とか記録しても。でも、レビュー前にレビュー対象物の作成方法において「如何にしたら指摘件数が増えないようにできるか」という議論もなく、単に指摘件数だけで品質管理するのはナンセンスもいいところですよね。こういう現場は、レビューによる指摘件数が少ないとレビューがちゃんとできてないなんて烙印を押すのです。 それから、これは今私がやらされてることなんですが、レビュー記録をつけるとき指摘事項の「分類」とやらを記載しなければならないことになっています。これは、簡単に言えばその指摘はケアレスミスを指摘したものなのか、それともレビューイの認識不足を指摘したものかなどの観点で記載するものです。 これは
レビューこそ品質確保の鍵（190～196日）
前回に続き、品質を確保するうえで重要な役割を果たすレビューについて考える。レビューは、設計内容を見て、先輩が若い設計者に設計のあるべき姿を教える絶好の場でもある。また顧客からレビューを受け、ベンダー側の誤解を指摘してもらうことが是非必要だ。 レビュー時に何もコメントしないレビュアーがいるのは問題であるが、座って聞いていてくれるだけでも効果があるという一面がある。被レビュー者（説明者）は、レビュアーの前で説明しながら、自分自身で自分のミスやまずさに気付くからである。 他人に分かりやすく説明するためには、内容が論理的にすっきりしていることが一番大事である。美しく、論理的に整然としていない資料では説明につまずいてしまうため、説明の過程で自分の設計のまずさに気付かされるのだ。まさに最高のレビュアーは説明者自身なのである。 レビューはSEや設計者の設計内容を審査し、間違いを事前に発見・修正する場であ
「レビュー」と工程ほど誤解されているものはない - Fight the Future
彼は最も酷いレビューのいくつかの例を次のように挙げている。 コーディングを行った開発者を脅したり攻撃したりする魔女狩りレビュー 深刻な問題は放っておいて、記述方法やインデントについて注力する中括弧論争レビュー レビュアーが事前にコードを見ることがなく、また事前準備もない状態でレビューに臨む盲目レビュー コードの一部のみをレビュー対象とし大事な箇所が対象として除外されてしまう除外レビュー レビューを行うことが不可能である、またレビューをしたとしても効果のないくらいコードベースが大きくなってから行う紙の無駄使いレビュー プロジェクト管理上こなさなければならない形式的に実施するトークンレビュー 大多数がプロジェクトに関係なく開発者を威嚇するために存在するような多人数で実施するワールドレビュー InfoQ: デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー (少なくとも僕が経験した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインやコードの良いレビュー、悪いレビュー、そして酷いレビュー
