Atusy's blogVim-jpラジオ#27と#28はt-wadaさんをゲストに迎えたEmacs回でした。
#25と#26もEmacsがテーマだったので、本編でも言われるように実質Emacs radioでしたね。 Emacsの魅力を通じてVimを再解釈できるステキな回でした。
#27・#28ではEmacsについて語る……と触れこんでますが、 実はEmacsというコアな部分を持つことで生まれたもの、得られたものの話だったように感じます。 Emacsを始めとしたOSSの存在にどれだけt-wadaさんが助けられ、成長したのかといった話や、EmacsにおけるREPL駆動開発がいかにテスト駆動開発の理解を促したかといった話がでてきます。
どちらの回もEmacsが起点で、Emacsの魅力に溢れてるわけですが、だからEmacsをやれとかそんな単純な話じゃない。新しい世界に触れることや、逆にコアの部分を大事にすることで、独自の視点が養われ、人として成長していくんだなと感じました。なんかこう書くと当たり前すぎる……。
t-wadaさんがゲストなこともあり#28ではテスト駆動開発（TDD）もがっつり掘り下げてます。 TDDが変化に耐えるソフトウェア開発を加速する認識はあったのですが、分かる小さいところから作っていく方法論でもあるという認識は新鮮でした。確かに仕様の全容が見えない大きなものを作る上で、まず分かるところから小さく作っていくというのは理にかなっているように思います。
おたよりへの回答では、テストの粒度や網羅率についても気にしすぎず、やれるところからやって単体テストの比重を高めていけばいいよというアドバイスをしていて、「まず分かるところから」という考え方が徹底されているなと感じました。
ところでREPL駆動開発といえば、私もRStudioで分析やパッケージ開発をしていた頃は、コードを部分的にREPLに送り込んで動作を見ながら開発していました。 RStudioでの経験から、現在の開発でもREPLやシェルで試している内容をテストに書いていくというやりかたをすることがあります。タイミング次第でテストファーストになったりならなかったりするのですが、わかるところから仕様を固めていくというやり方が共通しているなと感じました。また、わかるところから書いていくと、全体が破綻するようなケースは少なく、捨てるコードも2、3割程度で済むという話も共感できました。
余談ですが、こう感じられたのは、感想を書くつもりで話を聞いていたからかなとも思います。学習ではアウトプットを前提にしたほうがインプットの質もあがるよとはよく言われます。インプット対象が他者の経験談などになると、人を自分の鏡にして自己理解も促進されると気付けたのは、ちょっとした収穫に思います。
次回でvim-jpラジオは半年を迎えるとのことです。特段、めっちゃ良い話をするぞと肩に力を入れてらっしゃるわけではないと思うのですが、ただでさえ聞いてて楽しいラジオが、これからも色んな気付きをあたえてくれそうで、楽しみにしています。