アカウント名:
パスワード:
「こういうコードが恥ずかしいコードである」という価値観について、上級技術者間で意識統一がなされていればね。
ようするにコードレビューと言うのは、大学の研究室で言う輪講とかと同じなんです。コードをよりよいものにする、と言うのも目的の一つですが、コードを組んだ人のレベルアップを図る、という目的もある。
十分な人数の、良く判っているプログラマがいるならばペアプログラミングも良いでしょう。でもペアを組んで回れるほどレベルの高い人がいなかったら?「教授と助教授と助手の目の前で発表させる」しかないじゃないですか。
もちろん、この作業は「教授や助教授や助手」の時間を食います。もしあまりにも多くの時間を食うのであれば可能性は次の3つのどれか。
UIレベルのテストで問題がたくさん出てくるのですから 2 である可能性は低いですね。
1 かどうかは、レビューを受ける人とレビューをする人の人口比率を調査する必要があります。基本的に初心者と判りきっている人に、全コードレビューに参加させるのは得策ではありません。もちろん、良いコードを読むのは重要ですが、自分が組んでいる部分と全く関係の無いコードの、しかも最初のバージョンのレビューに参加しても得られるものは少ないでしょう。それよりも「直せ」と言われた部分を直す事に時間をかけるべきです。逆に全てのレビューに「教授・助教授・助手」レベルの人たちは参加する必要があります。実質的にコードの質を向上させているのはこの人たちですから。この人たちの時間がレビューに取られる、というならば、この人たちはコーディングをするべきではないのです。それでも足りないなら、プロジェクト全体の人数が多すぎる、と言う事です。
3 … えー、3かどうかは NDA を結んだ外部のプログラマを何人か雇って、彼らのコードレビューを受けるべきだと思います。それまで発見された問題とかなり違う問題点がいくつも発見されるようならば、 3 の状態である可能性は非常に高いです。
> 1. 初心者が多すぎる。そのため、「教授や助教授や助手」の時間をフルに使っても、全部など到底見切れない。コードの品質は悪いままである。> 2. 初心者が少なすぎる。コードの品質は最初から高く、いくら見ても時間の無駄である> 3. 「教授や助教授や助手」のレベルに到達した技術者が実はいない。なので見当違いな所を見ていたり、全員が同じ間違いを犯していていくらレビューしても品質は向上しない
結論:ほとんどの日本のIT企業においては、コードレビューは時間の無駄である。
通常は1&3。運が良ければ1だけのこともある。
しかしそうすると、日本においてちゃんとしたコードがかける人たちはどこへ行ってしまったのでしょう…
>しかしそうすると、日本においてちゃんとしたコードがかける人たちはどこへ行ってしまったのでしょう…もとより絶対数が少ないし、大量の初心者で水増しすれば相対的に熟練者の比率は下がるわけで。
そして、そのごく僅かの熟練者の命も長くはない。大抵は、1、管理職になる。2、営業になる。3、他の業界へ転職する4、外資系企業に入る。(肩書きはユーザーサポートだったりプリセールスだったり。)5、新天地(外国)へと脱出する。6、失業者になる。となるのでは?
#本命が1、対抗馬が2。大穴が4と5。
とりあえず「上級者は何人か居るんだが意見が割れたままなので内紛が収まらない」という状況は無視しときましょう。出現率が低そうなので。
>通常は1&3
その見切りが正しいとすれば(私もおおむね正しいと思います)、
●レビューが「必要」であるか否か、と、レビューを実際そこでやって「有意義」であるかどうか、とは別問題
ってことが言えるんですね。
必要なんだけど適切な人材が居なければ、やっても無駄。そして無論やらなくてもダメなまま。
結局は「適切な人材が居なければダメ」という当たり前すぎる結論に達するだけなんですが、こんな当たり前のことが満たせてない「職場」がどうも凄く多いようで…orz
#「日本のソフト屋は残念」率は高いと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
もちろん意味がありますとも (スコア:4, すばらしい洞察)
「こういうコードが恥ずかしいコードである」
という価値観について、上級技術者間で意識統一がなされていればね。
ようするにコードレビューと言うのは、大学の研究室で言う輪講とかと同じなんです。
コードをよりよいものにする、と言うのも目的の一つですが、コードを組んだ人のレベルアップを図る、という目的もある。
十分な人数の、良く判っているプログラマがいるならばペアプログラミングも良いでしょう。でもペアを組んで回れるほどレベルの高い人がいなかったら?
「教授と助教授と助手の目の前で発表させる」
しかないじゃないですか。
もちろん、この作業は「教授や助教授や助手」の時間を食います。もしあまりにも多くの時間を食うのであれば可能性は次の3つのどれか。
UIレベルのテストで問題がたくさん出てくるのですから 2 である可能性は低いですね。
1 かどうかは、レビューを受ける人とレビューをする人の人口比率を調査する必要があります。
基本的に初心者と判りきっている人に、全コードレビューに参加させるのは得策ではありません。もちろん、良いコードを読むのは重要ですが、自分が組んでいる部分と全く関係の無いコードの、しかも最初のバージョンのレビューに参加しても得られるものは少ないでしょう。それよりも「直せ」と言われた部分を直す事に時間をかけるべきです。
逆に全てのレビューに「教授・助教授・助手」レベルの人たちは参加する必要があります。実質的にコードの質を向上させているのはこの人たちですから。この人たちの時間がレビューに取られる、というならば、この人たちはコーディングをするべきではないのです。それでも足りないなら、プロジェクト全体の人数が多すぎる、と言う事です。
3 … えー、3かどうかは NDA を結んだ外部のプログラマを何人か雇って、彼らのコードレビューを受けるべきだと思います。それまで発見された問題とかなり違う問題点がいくつも発見されるようならば、 3 の状態である可能性は非常に高いです。
fjの教祖様
Re:もちろん意味がありますとも (スコア:2)
> 1. 初心者が多すぎる。そのため、「教授や助教授や助手」の時間をフルに使っても、全部など到底見切れない。コードの品質は悪いままである。
> 2. 初心者が少なすぎる。コードの品質は最初から高く、いくら見ても時間の無駄である
> 3. 「教授や助教授や助手」のレベルに到達した技術者が実はいない。なので見当違いな所を見ていたり、全員が同じ間違いを犯していていくらレビューしても品質は向上しない
結論:ほとんどの日本のIT企業においては、コードレビューは時間の無駄である。
通常は1&3。運が良ければ1だけのこともある。
Re:もちろん意味がありますとも (スコア:1)
しかしそうすると、日本においてちゃんとしたコードがかける人たちはどこへ行ってしまったのでしょう…
fjの教祖様
Re: (スコア:0)
>しかしそうすると、日本においてちゃんとしたコードがかける人たちはどこへ行ってしまったのでしょう…
もとより絶対数が少ないし、大量の初心者で水増しすれば相対的に熟練者の比率は下がるわけで。
そして、そのごく僅かの熟練者の命も長くはない。大抵は、
1、管理職になる。
2、営業になる。
3、他の業界へ転職する
4、外資系企業に入る。(肩書きはユーザーサポートだったりプリセールスだったり。)
5、新天地(外国)へと脱出する。
6、失業者になる。
となるのでは?
#本命が1、対抗馬が2。大穴が4と5。
Re: (スコア:0)
とりあえず「上級者は何人か居るんだが意見が割れたままなので内紛が収まらない」
という状況は無視しときましょう。出現率が低そうなので。
>通常は1&3
その見切りが正しいとすれば(私もおおむね正しいと思います)、
●レビューが「必要」であるか否か、と、レビューを実際そこでやって「有意義」であるかどうか、とは別問題
ってことが言えるんですね。
必要なんだけど適切な人材が居なければ、やっても無駄。
そして無論やらなくてもダメなまま。
結局は「適切な人材が居なければダメ」という当たり前すぎる結論に達するだけなんですが、
こんな当たり前のことが満たせてない「職場」がどうも凄く多いようで…orz
#「日本のソフト屋は残念」率は高いと思う。