@yohei さんの品質についての考え
YAMAMOTO Yohei @yohei まず、テストって言葉は広いからうまくどの「テスト」について話しているのかを切り分けないと混乱しますね。特に開発者テストといわゆる品質保証的なテストとが混乱すると悲劇。そういう意味でTDDって言葉は功罪あったと思う YAMAMOTO Yohei @yohei 僕がブックマークでコメントしたプロセスを強化する方向が楽だからというのは、何か問題が起きたときの対策として、その原因を突き止めてそれが再発しないことをプロセスに落としこむの方が楽だからという意味です YAMAMOTO Yohei @yohei もちろんプロセスの強化が必要な場合もある。でもそれってものすごく基本的なプロセスが間違っていたとか、ひどいミスが多発した場合に必要なことであって、プロセスの強化だけで何か解決しようとするのは本質的ではないのではないかと感じます。 YAMAMOTO Yoh
レビューの目的と進め方
レビュー会議が失敗する背景に，典型的な三つの原因がある。それらを回避し効果を高めるには，プロセスを踏み，3回に分けて実施するとよい。レビューの専門家に，その方法とコツを解説してもらう。 細川 宣啓 日本IBM みなさんの現場では，こんなレビュー会議をしていないだろうか。議論が発散して時間が掛かる割に，重大な欠陥を検出できない。議論が活性化せず，みんな下を向いている。なじり合いやケンカの場になっている─。 そもそもレビュー会議には，スキルの高いITエンジニアが参加するはず。それなのに，どうして冒頭のようなレビュー会議になってしまうのか。 筆者は現場の開発リーダーや品質保証部門という立場で，数多くのレビュー会議を見てきた。その経験からいえるのは，レビューが失敗に終わる背景には典型的な原因が存在し，それらを回避するための工夫やコツがある，ということだ。 以下では，組織的なレビューの要といえる「
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソースコードの品質向上のための効果的で効率的なコードレビュー
