2008年8月2日土曜日

アジャイルはソースコードの中にも。

今日は、Wicket勉強会に参加してきました!
会社はたまたま盆休みの休暇を出していた日だったし...会場は家からめちゃめちゃ近いし...ということで、用意してもらったような勉強会ww

業務でもちゃんと使って上手く行っている所が既にあるんだなー!

話の中で、コード量を少なくして設定で楽にする...というのを行なうと、Wicketの良さが半減してしまうんじゃないか?って話があったんですが、ここは考えさせられる所ですよね。
WicketはJavaでコーディングできるからこそ、楽しいし、設定とソースとちょこちょこ移動しなくていいからテンポがよくなるし...ってのでイイ!というのがありますものね。

ここは「バランスが肝心」ってやつなんでしょう。

処理パターンとか...作業メンバーのスキルとか...によっても変わるし、Wicketだからこうしなさい!というものは、やっぱり言えないですよね。

でも、”こぅいぅ方法がある”ということを知らないと、どうしよぅ?と考えたときの選択肢も増えない。
知識というのは、そのときに必要じゃなくても必要ですねー。

そういえば、テレビで脳科学者の茂木先生が、
新しい事を生み出すということは、今までの経験情報の引き出しから引っ張ってくる作業だ。

...ってな事を言っていました。(言い回しはちょっと違ったかも。。)
ソフトウェアを作るってことは、全く同じものを作る訳でないから、毎回新しいものの生み出し!なんですよね。

方法は色々知っておいて、自分で何かを生み出すときには、色んな引き出しを用意しておきたいものです。

懇親会は参加しなかったんですが...盛り上がったのかな?

家に帰ってからは、会社の後輩とSkypeでテストケースのパターンの話をしました。
テストケースって基本全てのパターンを網羅するってのは基本なんですが、それを真面目にやろうとすると、パターンの乗算的に考えていくと、現実的でない量になるので...どうしたらいいのか?という質問だったんですが....

ソースコードの作りがどうなるのか?も全く不明な状態だと、「全部のパターン網羅」としか安全な言い方はないんですよね。

でも、ここで、「じゃーこのパターンだけでいいよ」って指示を出してしまうと、「そのパターンが満たされていたらOK」として作業完了されるのも不安がのこるし...
しかも、ソースコード、テストケースを作成するのは、Javaの知識があまりない人達という前提もあって、回答は私には難しかった。

Javaを書き慣れている人がやるのであれば、同じようなソースを複数のソースに記述することはないだろうし、ソースコードの書き方からみて、ここらへんはヤバイから集中してテストをしよう。とかも分かるだろうし...って事で、ある程度は判断できると思うので始めはお任せして、実際ほかのテストでバグが見つかったらテストケースの追加...ってしていくのですけどもねぇー。

さっきのWicketの話題とちょっと似ているなと思うのが、
「これは、こうすべきだ」と定型化してしまうと、作業の効率が悪くなったり、ソースコードの見通しが悪くなってしまったり...ってなるのは、やっぱり避けられない。
新たに何かを生み出す作業なのだから、作業者が常に、”バランス”を考え、”変化に対応” していくのは必要なんでしょぅ。

一つのコードの中にもアジャイルの姿勢で効率化をはかれ ってことですね!

会社の後輩から、「え?これはしても良い事なんですか?」って言われるときが度々あります。こっちの方法の方がいい!と途中で思ったんなら、そのときに相談してよーって思ってしまう訳ですが、これって、後輩が新人の頃に「これは、こーやって作成して」って定型の指示を忠実に守ってきたから...ってのもあるんですよね、多分。

ここの所は、反省。

新人に対してであっても、教えることは、
「こういうパターンはこうやって実装するんだよ」ってことよりも、
「こうした方が、より良くない?と常に考えることだよ」って事を教えていく事の方が大事なのかもなぁー。
• • •