読者です 読者をやめる 読者になる 読者になる

おさかな日誌

魚類がプログラミング

Ruby 用天気予報ライブラリの weather_jp V2 出した

天気予報取得用の Ruby gem の weather_jp という gem を2年半前くらいに作ったのだけど、MSN が RSS 配信を止めたらしく動かなくなったので Twitter でメンションが来た。バックエンドを大幅に変えなくてはいけなさそうなのでせっかくだし V2 にした。

"V2 upgrade guides" という言葉を自分のライブラリで使う日が来てうれしい。使ってくれる人がいないと V2 を出すモチベーションがわかないから、V2 になれるくらいは貢献してるんだなぁ良かったぁ、という感じ。

2年半前の自分が書いたコードというのはプログラミング初心者(半年目)の自分が書いたコードというやつで、かわいがりがあるコードだった。

で、今回は前よりはまともに書けるようになったわけなんだけど、以前は困ったことがなんで今回困らなくなったか考えてみた。

前はまず「どの処理をどこに置くのがいいのか」ということにひたすら悩んだ。結果ドメインモデルのコンストラクタでデータフェッチする、みたいなひどいことになっていた。こういう API call されて、リクエストを元にデータフェッチして結果を返す、みたいな場合は大体層状アーキテクチャを頭に置いておいたらうまくいくような気がする。この処理はリクエストをパースするような処理なのか、ディスパッチするような処理なのか、データフェッチなのか、ドメインモデルへの変換処理なのか。DDD と DDD本読むために必要な知識群が役に立ちましたね...

あと当時は初めて自動テストを書いたので、なにがなんだかさっぱりだった。最初は自動テスト中に HTTP リクエストをサーバーに飛ばしていた。これくらいの粒度のライブラリをてっとりばやくテストを仕上げるには、レスポンスを予め保存しておいてデータフェッチの部分でスタブして保存したレスポンスを返して 、あとは一番外側のインターフェースからざっくりとテスト書いていって、C0 カバレッジを100%にするようにスタブしたりクエリを変えたりテスト追加すると C0 カバレッジが 100% になるころには大体バグが潰れている。ソフトウェアがシンプルだとテストもシンプルでいいしとても楽だ。

あとリファクタリングリファクタリングで自動テスト壊さずに進めるの大事だと思うんだけど、けっこう難しかったりする。今回はわりと上手くいってテスト壊さずに進めれたから精神的に楽だった。V2に合わせていろいろ変更する前に、気になるところを冗長でもいいから単にリファクタリングするだけにとどめておいたのが良かったのかなぁって思ってる。