HotDeploy、いつどこでだれと？

Java Architecture Programming

HotDeployとは？

Webアプリを再起動することなく、
修正したコードが反映されるHotDeploy。

画面開いて「あっ、まちがってる」と思ったら、
おもむろにそのままコードを修正して、
F5押したらすぐに修正内容が確認できる。

スクリプト言語では当たり前かもしれませんが、
コンパイル言語ではなかなかそれを手に入れるのに苦労します。

HotDeployを導入するためのコスト、
HotDeployがゆえに発生するトラブル、
もあるため、費用対効果として疑問視されることもあります。

「HotDeployあると便利！」
の一方で、
「HotDeployなくても気にしない！」
という声も。

jfluteも、まあHotDeployあった方がいいよね、
くらいにしか言えていませんでしたが、
ここ数年で感じたことがひとつあります。

「ベンチャーの事業会社ではHotDeploy欲しい！」

ということ。

その現場の特徴は？

リーンスタートアップ＆インクリメンタルな開発をする現場。

その大きな特徴としては、

o スピード重視
o すぐに業務は変わる

ある程度のコードのとっちらかしは仕方ない。
ドキュメントもちゃんとしたものは作らない。

リーンスタートアップな時期

リーンスタートアップな時期、
作りながらも作るものがリアルタイムで変わっていく。
作るものがしっかりと決まってる系の開発と違って、
じっくりコードを積み上げていって最後にがっつりテスト、
というような実装スタイルはなかなかしづらい。

コードを書きながらつどつど(ライトに)確認していって、
小さな単位でコードを積み上げて進めていくことで、
手戻りコストをできるだけ少なくする必要があります。

インクリメンタルな時期

インクリメンタルな時期、
他人の作った、もしくは、ほとんど他人に近い昔の自分が
作ったコードに手を入れていきます。

「これどうなってんだっけ？」

って、わからないと手の入れようがない。

「ちょっとここ、こう書き換えてみたらどうなるかな？」
「こう書いても平気なのかな？」

って感じで分析的なお試しコード修正をたくさんやります。

事業会社は猛スピードで成長していきます。
どんどん新しい人も入ります。
作るものがしっかりと決まってる系のような、
開発人数も最初から決まっていてあらかじめ確保する、
みたいな運用にはなりません。

業務ロジックだけでなく、ライブラリやフレームワークを
理解していく時間もなかなかありません。
なので、そういったレイヤも含めて「ちょっと試してみよう」
的なトライ＆エラーがプログラマーには必要です。

# ちなみに、
# jfluteがフォローイングさせて頂いているビズリーチでは、
# 入社したエンジニアの方々は、業務をやりつつDBFluteハンズオンで、
# DB周りだけでなくWeb周りや社内ライブラリを学んでいくので、
# よくある「使ってるものがよくわからない」問題はあまり起きず。
# ただ、やはり完全な習熟にはそれなりに時間もかかりますので。

HotDeployがスピードを呼ぶ

そう、単純にスピードを出すためのHotDeploy、
に加えて、既存コード分析のためのHotDeploy、
という役割が大きいなと感じるのです。

HotDeployがなく再起動に30秒かかるシステムと、
HotDeployがあるシステムとでは、
トライ＆エラーのサイクルスピードが断然違います。
ディベロッパーのストレスにも大きく作用します。
(作用しているのを感じます...)

まあ、HotDeployだったらそりゃそうだって感じですが、
ここでの論点は、
そのHotDeployによるスピードの恩恵を得るチャンスが、
「インクリメンタル開発では圧倒的に多い」
ということです。

逆にしっかり開発では不要？

jfluteは、HotDeployによる開発経験の期間が長く、
「HotDeploy育ち(温室育ち!?)」と言えるのですが...

逆にですね、こう考えてると確かに、
「作るものがしっかりと決まってる系の開発」では、
HotDeploy無くてもいいかもなって。

だから、HotDeployは必要だ、いや要らない、
という議論を正しくするためには、
「結局どういった状況の開発現場なのか？」
「なにを大切にするシステムなのか？」
などを考慮しないとだなぁと。

あればあるにこしたことはない、
ってのは全くのその通りですが、
それだとあまり費用対効果を絡めた議論が
できなくなってしまうので、
その「程度」をちゃんと分析しないとと思って。

もちろん、事業会社もいろいろだし、
作るサービスの内容次第だったりもするので、
結局はケースバイケースなのですが、
大きな方向性としてはこんな感じのセオリーが存在する
ってのをまとめてみたかったという感じです。

そりゃぁ、スクリプト言語はこの辺強い！

スクリプト言語の人から見れば、なに言ってんだ？
って感じかもですね、当たり前の話ですから。

事業会社で「Javaを使っている」って言うと珍しがられますが、
こういう開発スタイルの違いを考えると、
「そりゃまあ」という感じかもですね。

ただまあ、コンパイル言語にはコンパイル言語なりの、
「こういった現場で発揮するパワーがある」って話は、
jfluteがよく勉強会で話しています(^^。
今度の「渋谷Java」(９月２０日) では、
「一度ボツになったリーンスタートアップJava and DB」
というタイトルでいろいろ話します。
ということで、それはちょっと置いておいて...

HotDeployを得るためには？

コンパイル言語、というか、ここではJavaで
HotDeployの環境を整えるためには、のお話。
ちょっと苦労します。

【Seasar】
HotDeployというと、個人的にはやはりSeasar。
それ以外の問題はちょっと棚に置いておいて笑、
「使い方を間違えなきゃ」有用です。

そう、使い方を間違えなきゃ...

Seasar使ってるのにHotDeploy効いてないなんて!?
Seasar使ってる意味の 90% くらいが失われてる...
(人によってはすべてと言うかもしれません)
使い方を間違ってるとHotDeployトラブルも多発します。

jfluteがフォローしてるSeasar使ってる現場では、
明確にHotDeploy対象とそうでないもののパッケージを分けます。
HotDeployを効かせるのは、
画面の Action や Form と、あとは Logic とかくらい。
自動生成クラスはHotDeployにはしない。

以下ブログでもうちょい詳しく書いています。
「スマートデプロイとベタなものを分ける」のところ。

// jfluteが「Seasarどう？」って聞かれたら...
http://d.hatena.ne.jp/jflute/20140324/seasar

ちょうど最近、まさしくHotDeployが効いてないSeasarを
使ったプロジェクトでその辺を整備するチャンスがあって、
HotDeployがしっかり効くようになりました！
現場のエンジニアからは喜びの声を頂きました(^^。
(というか、jfluteも緊急時に分析がやりやくなった...)

【Spring】
Springでは、Spring Loaded と呼ばれるツールが
あるようですが、まだまだ実験的なようで、
聞いているかぎりの評判はいまひとつ。
ただ、そもそも完璧なHotDeployでなくてもよくって...

「効く効かないの線引きがはっきりしている」

ことが、とっても大切です。

先ほど話した、既存コードの分析であれば、
一文字だけ変えて再起動なんてこともざらですから、
それだけでも「確実に効く」であれば有用かと。
まあ、そのうち試してみますね。

JRebel と呼ばれる有償のツールもあるようです。
Springでも難なくHotDeployできるようになったら
めっちゃうれしーなーって切に思います。

というのは...
「SeasarよりもSpring！」
という声が日に日に強くなっていく今日この頃ですが、
jfluteとしては正直、
「どっちでもいいから HotDeploy させて！」
という感じでして。。。

事業会社、というかメンテナンスの現場だと、
「トラブルで緊急対応、緊急分析」がとてもたくさんあります。
トラブルと言っても、致命的なトラブルというよりかは、
「ビジネス上の致命的なトラブルなのか、そうじゃないのか？」
を判断するために、既存コードのスピード分析を必要とします。
その判断は「ネ申重要」です。
その判断を抜かして原因追及してはいけませんし、
Webサービスであれば秒単位での判断スピードが求められます。

まずは、ビジネス上の損失を回避するパッチ的な対応を真っ先に提案し、
それを対応してもらってる間にそのパッチ修正の妥当性のチェック、
(妥当性のチェックをしてからの提案では遅い)
そのパッチ修正が良さそうであれば、今度は根本の原因の追及、
ケースによってはそれは後でゆっくりでもいいときもありますが、
根本の原因がわからないということは、
まだ顕在化していないビジネス上の損失があるかもしれないわけで、
二番目の行動とはいえスピードは落とせません。

分析スピードは一秒...は言い過ぎにしても、10秒は大きな差です。
極端な話、1分待つくらいなら、違い判断を下すっていうのもあるかも。
現場のエンジニアは常にそういったプレッシャーと戦っているのです。
彼らをエンハンスする環境を提供したいし、
彼らの精神的負担を減らしたいし、と考えるのです。
(というか、そのフォローもjfluteの大事なお仕事のひとつ...)

そういったことを考えると、新しい古いっていうだけで、
安易にフレームワークを決めることはできないのです。
ということで、jfluteのSpringへのアプローチにおいては、
やはり Spring Loaded と JRebel はキーポイントになりそうです。

【Play2】
Play2 は普通に HotDeploy と聞いています。
とても良いフレームワークだと聞いています。
Play2ハンズオン はやりましたが、
jflute自身が実務で関わったことがないので、
どういう感じで使いこなしていくと良いのかまだ不明です。
アプローチするフレームワークの待ち行列に入っています。
(早くさわってみたいのだけど...)

そうだっ、コントリビュートしてもらった、
「DBFlute と Play2 Java のExample」を整備しないとぅ！

ケースバイケースの罠

「作るものがしっかりと決まってる系の開発」って表現、
わかりやすく「SIerの開発」ってあえて書いてないのは...

結局、SIerでもBtoCの事業会社にチームで常駐して、
運営に参加するってケースもあるし...
(昔々、実際にjfluteもそういう時期ありました)

業務システムでも変更の激しいメンテナンスモードの
開発チームで、同じような話が当てはまるも現場もあるし...
(昔々、jfluteの近くにありました)

なので、ちょっとうっとおしい書き方になってしまいましが、
難しいですよね、この多様化の時代で抽象概念を使った論理を
広げようとすると、ケースバイケースの罠にハマりやすいもので。

…
…

【追記】(2014/10/20)
Seasarのこと、ちょっと書きました。

// jflute と Seasar
http://d.hatena.ne.jp/jflute/20140925/seasar