亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

#tddbc 岡山に遊びに行って来ました!

一応C#のTAもしたよ!

ザクッと感想

というわけで、多分オフィシャルに教える立場って初めてだったんじゃないかなーという感じでTDDBC岡山に参加してきました。

当日朝入り。集合場所までの到着時間を見誤ったり集合場所で迷うなどがあって、ギリギリの到着に。。。

TAといっても二回目の参加なので、大阪との比較しかできないんですが、やっぱJava人口って多いんだなぁと時間しますね、こういうイベント。結構TAいたので自分でF#で課題やったりする時間有るかなぁ、と思っていたんですが残念ながらそんなことはなく。まぁなんとかTAの役目は果たせたかなぁと思います。

印象に残った議論とか

@pocketberserkerさんの発表


非常に面白かった。「不安をテストに」の「不安」とは何か?というのを知るためには、やっぱ品質保証のテストの視点も必要なのだなぁというお話とか、問題の分解をちゃんとやりましょう、という話とか。

特に「問題の分解」は最近自分の中で結構モヤモヤしていたので、自分なりの問題分解方法を色々考えて行かないとなぁ、というのはあった。

そういや参加者の人はマインドマップでTODOリストを作っているひとがいて、後の振り返りが凄くわかりやすくなっていたのでとりあえず真似してみよう。

privateのテストについて


この議論ね。このあとTL上では翌日の#javabseなどとでももう人盛り上がりしていてなかなか興味深かった。

個人的には「テスタビリティを上げることによる設計の改善」も重要だと思っていて、その恩恵をきっちり受けるためにもprivateメソッドをテストせざるを得ない状況に陥るのは好ましい状態ではないと思っています。TDDでやっている上でもそうだし、レガシーコードを改善する上でも、目指す形はそこにあるはず。

ただそれはあくまでDevelopper Testの観点で、かつ設計の改善という本来テストのスコープ外のことまで含め用としているので、例えば古いコードの不安をさっさと消してリファクタリングにかかりたいならそれはprivateメソッドのテストでいいとはお思う。

気をつけたいのは、@pocketberserkerの話にもあったけれど


  • 品質保証のテストとTDDを混同しない。

  • 「不安を消すこと」を優先する。


の二点を意識しつつ、自分の中ではpublicのみのテストを基本にする、でとりあえずいこうかと。

そういえば発表してた。


言いたいことはだいたい最後のスライドにあるよ!

いや、.NETな人たちの中にはIDEを全然使いこなせてない人っているんですよね。特にVSの拡張機能はかなり強力なのも多いし、拡張機能マネージャやNugetでいろいろ導入のハードルは下がっているので、IDE使いにくいとぼやくのではなく、自分好みに調教していくVim的、Emacs的視点を持ちましょうよ、というのが言いたいですね。

しかしJavaのIDEもどんどん素敵になっていますねぇ。こうなってくるとMonoDevelopが若干非力に見えてしまうという。。。Haxeとかも動くんだよMonoDevelop!!