議論の対象となる「レビュー」というプロセスに関する説明がザックリ過ぎる。
- 目的
- レビューというプロセスの役割と責任範囲
- レビュアーとレビュイーが担うべき役割と責任範囲
これくらいはちゃんと書いて欲しい。
レビュイーの技能を伸ばす事だけが目的ではない筈。
一定水準以上の前提条件がありながら、それを記述しないのは怠慢である。
加えて「意味不明な部分を削除する」事の意味について掘り下げるべきである。
「分からない」という言葉は、レビュアーとレビュイーにおいては、
最低限以下の様な項目において象限を構成する。
- 実装技術の差
- 問題領域に関する知識の差
それぞれの象限において意味が全く異なるので、適切な説明を求めたい。
最も分り易いのは、実装技術と問題領域に関してレビュアーとレビュイーの間に能力的な差分が有意に存在しない場合。
この場合には、「分からない」を連発しても特に問題ないと思われる。
レビュアーとレビュイーのどちらにとっても有意義な時間となるであろう。
最も最悪なケースは、実装技術と問題領域に関してレビュイーよりもレビュアーの能力が大幅に劣っている場合。
レビューの体裁を持っているかもしれないが、殆どの場合レビュイーにとって有意義な時間とは為らないであろう。
僕がレビューする場合、「何故そうなのか？」を重視する。
コードを書いた人間が、そのコードの意味や価値、トレードオフを適切に理解しているかどうかが肝要であって
「分からない」は間違いなくそれを含んでいるが、表現として広すぎる様に思う。
高度なレビュー技能を持った人が、その技能について論理的な説明が出来ない可能性はあるが、
その人がレビューをシステム的に捉える事が出来ていないだけであって、当人の技能不足である。
単に技能が不足しているだけの人の意見を引用しても意味がない。
そうしてしまうと、レビューは再現性の無いプロセスである事を全面的に肯定してしまう事になる。
レビューの上手い何とかさんの話は全く不要で有害。
レビューが比較的再現性の低いプロセスである事自体は肯定せざるを得ないが、
元の文章にもある通りツールやそれに伴うプロセスによって、
最低限の品質を底上げする方法が何がしか存在する筈であり、
この様な文章を書くのであれば、その何がしかを模索するべきである。
レビューが上手いとか下手と言うのは、具体的にどういう技能なのか説明するべきである。
少なくとも以下の様な項目に関する説明が必要であると考える。
- レビュアーとしての技能に関する評価軸
- レビュイーとしての技能に関する評価軸
- レビュープロセスを運営する技能に関する評価軸
レビューというプロセスに関する問題の1つがコストであるとするならば、
どの様なコストが、どの様なツールによって、どの様に低減されうるのか考え方を書いて欲しい。
非常に興味深い。
- ピアレビュー
- 薄い、軽い、オススメ
- ソフトウェアインスペクション
- 厚い、重い、ガチ
- アナタはなぜチェックリストを使わないのか？
- 参考程度に。
社内向けで全員がある程度出来る人向けで、さらに対象はある特定の人向けに書いた文章なので ... 。ただ突っ込みありがとう。