git flow やってみた

今の会社に入ってから、git flow で開発をしている。
個人的には github flow の方が好きなのだが。。。

git flow と github flow の何が違うのか。
簡単に言うと「どこまでマネージメントするか」、「どこまで個々のプログラマの自主性に任せるか」っていう事だと思う。

当然、github flow の方が git flow よりもプログラマの自主性が高い。
そのため、プログラマからしてみると git flow は管理されている感が強いだろう。
また、git flow だと管理する側が「管理する」という工数が増える。
そういう所が、自分が git flow をあまり好きではない所だ。

一方、git の運用方法はそのプロダクトの品質に間接的に関わってくる。
品質とは、バグ、セキュリティ、応答速度、スケーラビリティ、拡張性、オペレーション、ヒューマンミスの発生しにくさ等である。
そして、システム全体の品質とは、そのシステムの一番低いところで決まることが多い。
バグがなく、応答速度が早くて、スケールして…という一見して素晴らしいプロダクト出会っても、セキュリティがズブズブであればそのプロダクトの品質は低いのだ。

git の運用方法はバグやセキュリティホールの改修速度、リリースバージョンの安定性等に関わってくる。
つまり、プロダクトの品質へ間接的に関わってくるのだ。
(もっとも、過去の履歴がどうであれ即座に修正してしまうスーパープログラマにお任せするのであれば、git の運用方法なんて関係無い。
なので、「間接的」と書いた)

そして、git の運用方法もまた、開発者の最低ラインが全体のレベルに関わってくる。
git flow は開発者間の git の運用レベルに差がある場合、最低ラインを引き上げる良い方法の一つだ。

なので、結論
プロダクトの品質の最低ラインが改修速度やリリースバージョンの安定性であり、
その改善に際し個人技に頼りたくない場合は git の運用方法がプロダクトの品質を決める事がある。
そのような場合、git flow を導入する事でプロダクトの品質が上がるかもしれない。
逆に言うと、それ以外の場合は git flow なんて導入しても無駄な気がする。

個人的には、わざわざ git flow を導入するよりも一定レベルのプログラマと仕事したい。
それが無理なら、運用で縛るよりも教育したい。
そんな事を思いつつ仕事をする今日このごろ。

1ヶ月間 Meteor で開発してみて

新しい会社に入ってから、Meteor というフレームワークで開発をしている。
ちなみに、Meteor というのは Javascript 用の Web アプリケーションフレームワーク。
今まで、Javascript を本格的に勉強した事なかったので、自分にとっては色んな意味で新しい。

1ヶ月触ってみて、軽く Meteor の紹介と感想について。

まず Meteor の紹介。

Meteor は前述のように Javascript 用の Web アプリケーションフレームワークだ。
特徴としては、サーバーサイドとクライアントサイドの両方一度に開発しようという発想。

  1. 最近は、PC やスマートフォン等、クライアントサイドの性能が上がってきた
  2. 何から何までサーバーでやるより、クライアントサイドでも処理した方がサーバーの負荷も減るしユーザーの体感速度も上がるんじゃね?
  3. クライアントサイドでも処理するなら、サーバーとクライアントでコードを共有できると DRY だよね。
  4. じゃあ、サーバーサイドとクライアントサイドでコードを共有する事前提に、両方一度に作るためのフレームワークつくろう

こんな感じの思想に基いて作られたフレームワークとの事。

また、サーバーサイド、クライアントサイドともに MongoDB の使用が前提である事も珍しい特徴だと思う。
もちろん、サーバーサイドでは他の DB を使用する事もできる。でもフレームワークとして第一にサポートしているのは MongoDB。
そして、クライアントサイドでもメモリ上に MongoDB (正確には mini mongo というらしい)を立ち上げ、必要なデータだけサーバーと sync する。

作って見ると驚く程簡単で、Javascript 初心者の自分にもヌルヌル動くアプリが簡単に作れた。
色々と画期的なツールだと思う。
何より、クライアントに要求することが「Javascript の動く Web ブラウザー」だけという事が素晴らしい。
これひとつで、Windows, Mac, iOS, Android, Linux 等、一般ユーザーの使用している主要なプラットフォーム全てに対応出来る。

ただ、個人的にはあまり好きになれなかった。

まず第一に、サーバーサイドとクライアントサイドでコードを共有できる事のメリットが自分には感じられない。
入力データのサニタイズとか、確かにサーバーサイドとクライアントサイドで共有できると楽かもしれない。
でも、(サーバーサイドで Javascript を使うという前提であれば)その程度の事は一手間かければいくらでも出来る。
例えば、共有する Javascript ファイルを Web にあげておけば、クライアントでも読み込む事は可能だ。

「その一手間を除いたことが重要」という人もいるかもしれないが、そのために失う物があまりにも大きい。

では、Meteor を使うことで失う物とは何だろうか?

第一に、Meteor ではサーバーサイドでも Javascript と MongoDB を使用する事を強制される。
個人の好みの問題かもしれないが、副作用だらけの関数をイベント駆動で動かしているコードをデバッグすることは苦行だし、一切の型チェックを放棄している MongoDB はバグの温床にしか見えない。
もちろん、必要に応じて Javascript や MongoDB を使うことは全く問題無い。
でも、デフォルトが Javascript と MongoDB っていうのは個人的にいただけない。

「Meteor を使用していても他の言語や DB と組み合わせて使うことは可能だろ」って?
それはその通り。
でも、その手間を考えたら Javascript ファイルを Web 上に置いておく事なんて些細な問題だ。

第二に、クライアントとサーバーが密結合になりすぎる。
そもそも、REST っていうのは様々なクライアントから使えるという売り文句で 200X 年代にクラサバ型のシステムを駆逐してきた。
でも、Meteor で作ると「クライアントは Javascript を搭載した Web ブラウザー」という事が前提になってしまう。
Java で作ったアンドロイドアプリや curl を使う shell script とは相性が悪い。
このような構成は、俺の美意識に反する。

色々とケチをつけてしまったが、個人的な好き嫌いの問題だ。
Meteor は好みにマッチすれば強力なツールとなるだろう。
まだ新しく、未完成なツールである事も魅力に感じる人もいるかもしれない。
今から始めれば、2,3 年後に自慢できるかもしれないし、初心者でもコントリビュートできる事が多い。

何より、サーバーサイドとクライアントサイドをこのレベルでまとめたフレームワークを、自分は他に知らない。
俺のハートに直球ドストライクではなかったが、良い勉強にはなった。

興味のある人は、ぜひ勉強してみると良いと思う。