2016年2月18日木曜日

チヌかかり釣りMEGAの開発でやらなければよかった4つのこと

チヌかかり釣りMEGA(以下MEGA)を公開、運営しはじめてから来月で丸5年になる。また、公開時からホストサーバとして使用してきていたExpressWebがサービスを今年で終了するということで色々とこのプロジェクトの開発を振り返った際に「あぁこうすりゃよかったなぁ」と後悔したことをまとめておきたい。


1、Microsoftの技術は使うべきではなかった
誤解してもらいたくないのでひとまず断わっておくと私は.NET1.0からの.NET開発者である。仕事ではASP.NET, ASP.NET MVC, Windows Forms, Silverlight, WPF, SQL Server等々とどっぷりとMSの開発環境で経験を積んできている。その流れでMEGAの開発の話がビジネスパートナーとの間であがったときに自然とASP.NET MVCとSQL Serverを選択してしまった。しかし、この選択は今でもなんやかやと足をひっぱっている。主に費用面で。

そう、MSの製品を使うと高いのだ。

まずサーバは必然的にWindows Serverとなる。今なら.net coreとかあるのでLinuxでも動作させられるのだろうけど5年前にはそんなものは影も形もなかった。またSQL Serverは他のDBに比べて余計にお金がかかるし、仮に自前のサーバを建てたとしてもライセンス料もろもろが発生する。

私はMSの開発環境は大変好きなのだが、それが自分のビジネス(超小規模)に向いているとは言えない。MS製品は潤沢な資金を持っているお客さんを捕まえたときに使用するべきものだと思う。


2、一つの技術で作るべきだった
実はMEGAは色々な技術で構成されている。
  • メインのサイト
    ASP.NET MVC(C#)、SQL Server
  • 渡船店(余談だが渡船は「とせん」と読む)独自のホームページが更新されたかをチェックするチェッカー(Cron)
    Django nonrel、Google App Engine(Python)
  • 渡船店のホームページから釣果を抜き取ってくるCron on Ubuntu
    Node.js(Javascript)、Backbone.js、Mongodb
  • 独自広告設定用のサイト on Ubuntu
    Node.js(Javascript)、Backbone.js、Mongodb
  • ちぬあたりMEGA(ゲーム)
    CreateJS(Html版)、Android(Android版)
と、まとまりの無い状況になっている。なぜこうなったのか!?

なぜこうなったのか!というと、もうね、やっぱり初手でMSの技術を選択したってのが大きいと自分的には感じているのだけど、それ以上にその時々で流行りの技術に興味のおもむくままに手を出してきたってのが一番悪かったと思う。一応その技術を選択した背景にはそれなりの技術的な理由があるのだけれども、チェッカーを作ったころの2011~2012年あたりはNoSQLが流行りだしてたころで、「おっ、GAEなら無料でサイトもホストできんじゃん」という安易な考えを助長する状況だったのも悪く働いた。この記事を書くにあたって当時書いてたコードをざっと見てみたけど、もうね、ほんときれいさっぱりPythonとか忘れてるから。数年前にコード書くのに勉強して、数ヶ月だけ使って、それ以来使ってない言語とかSyntaxレベルで忘れるからね。仮にチェッカーを手直しする必要が出てももう無理だよ。むりぽ。

さらにチェッカーの開発環境が何だったかさえ定かではない。PC買い替えに伴い、日常的に使わない開発環境を構築しなかったために大和の主砲のロストテクノロジーばりにどうやって開発してたのかさえ分からない。どうすんのこれ状態だ。


3、流行りの技術に飛びつかない
2の続きなんだけど、カッティングエッジな技術とかが話題になっていると気になるし調べちゃうとどうしても使いたくなってくる。で、それで何かしら作っちゃう。でもね、これはほんと危険。まず開発環境が違うので時がたつと確実に環境構築方法を忘れる。環境が残っていればよいけどPCの買い替えなんかがあったら大変だ。でも必要に迫られて数年前に作ったものを修正しようとするとどうやって開発してたかを覚えていない。IDEは何だったのか、どうやってコンパイルしてたのか、Webサーバはどうやって起動させてたのか、などなど思い出すのに苦労する。試行錯誤しながら環境構築するのは面倒なのでモチベーションがあがらず時間もかかる。

サンドボックス的にお試しで最新技術をちょろっと触る分には良いと思うけど、何らかのプロジェクトの一部分にプログラミング言語やらプラットフォームが異なるものを混ぜ込ませるのは本当に避けた方が良い。

たとえば全文検索機能が必要になったときにSQL Serverをすでに使っているのならばFull Text Searchを検討するべきであって、Lucene.Netなどに特段の理由もなく浮気するのは後々面倒な事態に直面することが予想されるので避けるべきだ。


4、安定した技術を使うべき
Node.jsはライブラリも豊富で開発もやりやすかったのだけれども、保守の観点から考えると最悪である。私がNode.jsで開発しはじめたときのバージョンは0.6.9だった。その後、必要な機能の実装も終わり運用を開始し、一年後ぐらいに機能追加した際にNode.jsのバージョンを0.10.1だかに更新しようとしたところ失敗してしまった。なぜかというと、使用しているライブラリの大半がそのバージョンに対応していなかったからだ。

Node.jsのバージョンアップは使用しているライブラリが増えるほどに難しくなる。バージョンアップをすんなり成功させるのはほとんど無理じゃないかな。DLLヘルならぬnpmヘルだ。最新のNode.jsの環境では何らかの解決方法があるのかもしれないけど。

で、今現在のNode.jsの最新バージョンを調べたらv5.6とかになっている。私の環境とメジャーバージョンで5も違う!2~3年でバージョンが5もあがってんのかよ。なんじゃそりゃ。バージョンアップしようにも作り直しに近い形で手を入れないといけないので、とてもじゃないけどそんなことはできない。

このように若い技術は変遷が激しい。互換性を保ったまま移り変わっていくのは難しいので大抵新しいバージョンになるとインターフェースが変わっていたりして動かなくなる。しかもその変わり方が非常に激しい。その技術をメインで扱っているのならそれでもやっていけると思うけれど、つまみ食い的に手を出して、作った後はしばらく放置するような状況の場合は本当に負担になる。


まとめ
MEGAはビジネス的には全然成功していないのでそこらへんを念頭に置いて下記のまとめを読んでもらいたい。
  • お金のかかる技術は使うべきではない(例:MSの製品全般)。ただ、お金があるならこんなことを気にする必要はなし
  • Webフレームワーク、Database、Cron、他のなんらかの便利スクリプトなど、できるだけ同一のプログラミング言語、技術、プラットフォームでまとめる。同じIDEが使えると環境構築の手間も省けて楽
  • 保守を第一に考えて、安定した、こなれた技術を使う。移り変わりの激しい技術はメインで使うのでもきついのに、それがサブだったりしたら本当に大変
ある程度の経験のある開発者ならば言語、技術の違いなどは大した問題ではないのだけれど、プロジェクトの保守、運用を考えた場合に、とくに小さなチームや独りで開発している場合などは、それらの違いが大きな負担になる。これは無用の負荷なのでできるだけ避けるべきである。ヒソカが言うところの「メモリのムダ使い」というやつだ。そんな無用なところに気を使うのではなく、製品の品質向上、機能追加にこそリソースを割くべきである。

と、後悔はつきないけど、具体的にどういうテクノロジーをMEGAのために今後取捨選択したら良いかは今のところ何も思いつかない。

0 件のコメント:

コメントを投稿