だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？

先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。

モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。

最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。

assertThat(get(100), is("コーラ"));

みたいなテストを書いて。

String get(int money) {
  return "コーラ";
}

みたいな実装を書いた。爆速！

次に「200円を入れてボタンを押すとオレンジジュースが1本買えること」と言われ。

assertThat(get(200), is("オレンジジュース"));

実装はこうなった。

String get(int money) {
  if(money == 200) {
    return "オレンジジュース";
  }
  return "コーラ";
}

その後は

200円でコーラが2本買えること→( ﾟдﾟ)ﾊｯ!「getOrangeJuice()とgetCoke()に分ける？」
コーラの在庫を追加することができること→( ﾟдﾟ)ﾊｯ!「・・・ざ、いこ・・・？」
900円入れてコーラを2本とオレンジジュースを2本とビールを1本買って100円お釣りが出てくること→( ﾟдﾟ)ﾊｯ!「ボタンが必要・・・？てか、お、お釣り？」

とかなりながら、だんだん遅くなりながらも、要件を全て満たすだけのコードを書き続けた。

は、要件は満たすけど、色んなif文に溢れ、在庫を減らす処理はいくつかの場所に散らばって（たしかビールの在庫は減らなかったと思うw）、「あぁ・・・」という感じのものだった。

僕らが「え？在庫なんてあるんですか？」というと、POは「ふつー自販機ならあるやろー」って言ってた。まぁ、自販機ならそりゃそうよなー、と思いつつ。でも普通のプロジェクトで「そんなの普通あたりまえでしょ？」とか言っちゃうPOだとたぶん開発うまくいかないだろうなーとか思いながら聞いてた。

それと、POはしきりに「聞いてくれていいよ」と言ってはくれてたけど、でも自分から「このプロダクトをチームと一緒に良くしたい！」という気持ちは見えなかったなぁｗ

途中でメンバーの中では「色んな商品を取り扱えるように、Productクラスを作った方が良いのでは？」という意見が出てきた。その段階では、要望には、コーラとオレンジジュースしかなく、この後、本当に商品が増えていくのかどうかも分からなかった。

をバーっと1時間の中で経験して、みんなと「もうちょっと設計をちゃんとやった方が良かったかもしれないね」みたいな話もした。

で、ぼーっと考えながら。「これって、うまくいかないプロジェクトの縮図っぽいなぁ」と思った。

んで、おまけで、

みたいなね。

あれ？(´・ω・｀)

そのあいだなのかなー？

目の前のことに追われすぎない、かつ、分からない先のことを想像で考え過ぎない。

だから、何かに気づいたときに、それを元に全体をリファクタリングする。できるようにしておく。というのが大切なのかなって思った。

「在庫」という概念を発見したら「在庫をどうもたせるべきか」というのを考えてリファクタリング。

たぶんそういう発見はブレイクスルー的なリファクタリングになるから、ため息をつきながら、プレッシャーでドキドキしながら、やる。

そのためには、スキルと勇気と変更容易性が必要。

というところなのかなー。

それと「自販機」というものを知って、早く小さくブレイクスルーを起こすために、POはもっと中から発言をすると良さそうかなー。

誰も知らない新しいものを作るときは「全員の知識を持ち寄って、変化(発見)に対応し続ける」というのができたら良いのかなーって思った。

おわり。