<< 前 ホーム 次 >>

bakaid: 20101228

これは自分の反省でもあるんだけど。

継続的統合をやってると、作り壊しっていうのが、どうしても
避けられないのね。

作り壊しっていうのは、ある機能を変更や追加したときに、
他の機能を壊しちゃうっていうこと。

で、そのために回帰テストだとか、自動テストだとかを
やるわけだけど。でも、テストで作り壊しちゃったことを
知ることはできても、防げるわけじゃない。

作り壊しを避けるには、変更を加える機能だけじゃなくって、
その変更の影響範囲も見極めなきゃいけない。でも、
そんなもん、なかなか見切れるもんじゃないんだよね。

で、実際に作り壊しちゃったと。まぁ、簡単に直せるん
なら直しゃいいだけなんだけど。

ハマるパターンの典型がモグラ叩きってヤツ。こっちを
直したらあっちがダメになっての繰り返しになるパターン。
こうなったときは、腰を据えて設計を見直すとかしないと
ダメ。それこそ見切るくらいのつもりで。

もうひとつ、確かに回帰テストは失敗するんだけど、
仕様変更にしちゃってもいいんじゃない?っていうケース。
要は、製品コードじゃなく、テストのほうを直しても
いいんじゃない?っていう。

まぁ、実際、テストのほうを直すこともあるんだけど。
数値を見るテストなんかは変更の影響を受けやすくって、
テストが仕様の変更に追いついてないっていうことがある。

でも、そんなのはほんの少ししかないんだよね。

安易にテストを直す、つまり仕様変更を許しちゃうと、
テストの意味が薄まっちゃうんだよね。やっぱり、テスト
直すのって後出しジャンケンみたいなもんだしね。

それと、やっぱり、製品コード直すより、テスト直すほうが
楽だよね。でも、そういう安易に流れる姿勢は、必ず品質の
低下をもたらすと思うんだよね。品質のハードルを下げちゃう。

だから、作り壊しちゃったときでも、安易に妥協しちゃ
ダメなんだよね。そこで踏ん張らないと。

--

だから、自律心ってのがほんとに大切なんだよね。

ちょっと話が変わるけど、マニュアル仕事ってあるでしょう。
マニュアルに従って作業するだけの簡単な仕事。

まぁ、確かに、やらされてるほうは退屈だよね。

でも、自発的にマニュアルを作るんだったら話は変わって
くるでしょう。

マニュアルを作るっていうのはルールを作るようなもんで。
それを自分たちで作って自分たちに課すわけで、それは
自律ってことだよね。

『どこでも、誰でも、簡単にモノが造れる』って聞くと、
マニュアル仕事のように感じるけど、でも、それを実現
する道程はマニュアル仕事じゃないし、新しいモノを
造るとなれば、また新しいルールを探すことになるし、
そういう過程がずぅっと続くわけだよね。で、そういう
過程に参加できれば働きがいも感じられるんじゃないの?

--

一人が生み出した工夫をみんなに広めればマニュアル
というものになるっていうこともいえるんじゃないかな。

本家Permlink

<< 前 ホーム 次 >>


Copyright © 1905 tko at jitu.org

バカが征く on Rails