Quipper で最初のリリースなので振り返る

5月に Quipper に入ってやっと最初のリリースが迎えられそうな中、チームのメンバー全員がなぜかブログを書き始めた。なんなのこれ...

同調圧力は見て見ぬふりをしてたけど、外部のブログ圧力に負け僕も書くことにします。

Pull Request の粒度

6月に最初は開発者4人でスタートして、8月に Android 開発者の @dagezi さん、9月に @mizchi さん、で9月途中くらいから @hakobera さんにリリースマネージャとして入ってもらった。 4人メインでいると Pull Request の粒度はどんどん小さいものになっていてちゃんと Pull Request が回るのは4人くらいからなのかなーと思った。レビューしてマージする流れが早ければどんどん粒度も小さくなっていくけど、これが2人しかいないとかだとどうしても Pull Request の粒度も大きいものになってしまってレビューも更に時間がかかる、という感じになる。

ピークの時は小さいものもどんどん送るので月500個くらいチームとして Pull Request 投げてたと思う。リポジトリは結構たくさんあって、client, api, plugins みたいな感じでも別れてるので、pending-pr みたいなツール作って朝出社したら Jenkins からリマインドしてもらうようにした。

Brunch + Chaplin.js よかった

作ってたのは HTML5 アプリ(HTML + CSS + JavaScript のクライアント) で最初フレームワークとか何を使おうと色々考えたけど、@fujimura さんが brunch + chaplin.js がよさそうということでそれを選択した。 brunch は結局必要になるいろんなものが最初から全部あるので使ってみた感想としてはよかった。特に最初からテストがすぐ動かせるというのは大きいと思う。アプリケーションは S3 + CloudFront で動かしてる。(API は heroku)

とはいえ、完全に client と API を分けなくてもよかったのかなーともちょっと思ってる。特に end2end テストが色々大変になるとおもった。

過剰なテスト

JS で基本的にはテストを書けるところは書いてたと思う。とはいえ、自分は本当に効果的なテストが書けてたかというとそうでない箇所も多かった気もする。このプロジェクトよりも昔に刺身さんに「ここのテストいりますかねー？」とか話したら「自分だったらこのテストなら30分で書けるので本当に必要じゃないかもだけどとりあえず迷ったらつけとく」みたいなことを言ってて、それ以来自分もこの言葉は印象に残ってて迷ったらつけるようにしてるけど、過剰なテストは明らかにあってそういう のを今後は省いていきたいと思った。

ソフトウェア開発つらいみたいな話

スクラムっぽい感じで最初は進められてよかったけど、やっぱ8月の途中くらいから本格的に忙しくなって、いわゆる古典的なソフトウェア開発つらい... みたいな感じになった。このあたりは今後の改善もあるだろうけどもなんでなのかなーとはすごい思った。2013年だし気合みたいなので乗り切らなきゃいけない感じなのを改善したい。

小さく作って、作りなおす

今回の自分達のチームは Brunch + Chaplin.js で作ったけど、ロンドンで今動いてるチームは素の backbone.js + grunt で作ってて特にこれにする、という強い決まりがないのが個人的にはすごいいいなと思ってる。

以前ライブラリとかシステムの持続性みたいな話を @masatomon がしてたことがあったけど、「筋のいいのは生き残るという自然淘汰があると信じたいけど、そうでもない気がするし、筋がいいのを見抜けるかどうかもわからない、やっぱ、一個ずつのシステムを小さく作って、2年ぐらいで作りなおすのがいいんじゃないだろうか」ということを言ってた。実際 quipper のシステムはすごい疎結合になってて、プラグインみたいな機構もあるし、小さくモジュール化したシステムになっている。ただ一番の強みは役員であり技術チーフの人がそういう意識を持ってるのが心強くていいなーと思ってます。

まとめ

とりあえず今回は Ruby 3割、JS (Coffee) 7割くらいでずっと JS メインのプロジェクトはやりたかったので大変ではありましたが楽しかったです :) あと開発者も募集してるそうです。(アジアに飛ばしてほしい)