成功と失敗の経験が、今の自分のプログラミングの方法論を支えていると仮定する。 失敗というと設計が下手糞で後から手を入れるのが一苦労だとか、 負荷でサーバーが落ちかけたとか、まあそういうイメージ。...
成功と失敗の経験が、今の自分のプログラミングの方法論を支えていると仮定する。失敗というと設計が下手糞で後から手を入れるのが一苦労だとか、
負荷でサーバーが落ちかけたとか、まあそういうイメージ。
だとしたら新人教育の課程でも、成功と失敗を体験させるべきでないか。
ただしフルで失敗を体験させるとなると、
保守性の悪いプログラムがリポジトリに入っちゃうとか、
サーバーが落ちるとかの副作用があるし、時間がかかりすぎる。
例えばコードレビューで「その設計は駄目だ」と言うことは、
彼ら彼女らにとっての「失敗の経験」になりえるのだろうか。
もしそうなら保守性は保たれるし、サーバーは落ちないし、回転も早くなる。
僕はあんまりコードレビュー等を受けてきてなくて、
実際に動かしてみたらいまいちだとか、
後から手を入れようとしたらいまいちだとか、そういう経験が多い。
多いんじゃなくて印象に残っているだけかもしんないけど。
だからいまいち効果が予想できない。
でもこういうのってプログラマー固有なのかもしんない。
企画職の人って、イメージなんだけど、新人のうちからフルに仕事を任されて、
予算つっこんでみたけど全然回収できませんでした。
でも次からはこの経験を生かします。
そういうことってないんじゃないの？
企画を練って偉い人のところに持っていって、
「駄目だよこんなの。全部練り直して」とか言われているような。
本当にただのイメージなんだけどね。
だとしたらレビューは効果があるのかもしんない。
Atom Feed