修正したコードが反映されるHotDeploy。画面開いて「あっ、まちがってる」と思ったら、おもむろにそのままコードを修正して、F5押したらすぐに修正内容が確認できる。スクリプト言語では当たり前かもしれませんが、コンパイル言語ではなかなかそれを手に入れるのに苦労します。HotDeployを導入するためのコスト、HotDeployがゆえに発生するトラブル、もあるため、費用対効果として疑問視されることもあります。「HotDeployなくても気にしない!」という声も。jfluteも、まあHotDeployあった方がいいよね、くらいにしか言えていませんでしたが、ここ数年で感じたことがひとつあります。「ベンチャーの事業会社ではHotDeploy欲しい!」ということ。その現場の特徴は?リーンスタートアップ&インクリメンタルな開発をする現場。業務は変わるある程度のコードのとっちらかしは仕方ない。ドキュメントもちゃんとしたものは作らない。作りながらも作るものがリアルタイムで変わっていく。作るものがしっかりと決まってる系の開発と違って、じっくりコードを積み上げていって最後にがっつりテスト、というような実装スタイルはなかなかしづらい。手戻りコストをできるだけ少なくする必要があります。他人の作った、もしくは、ほとんど他人に近い昔の自分が作ったコードに手を入れていきます。「これどうなってんだっけ?」って、わからないと手の入れようがない。「こう書いても平気なのかな?」って感じで分析的なお試しコード修正をたくさんやります。事業会社は猛スピードで成長していきます。開発人数も最初から決まっていてあらかじめ確保する、みたいな運用にはなりません。業務ロジックだけでなく、ライブラリやフレームワークを理解していく時間もなかなかありません。的なトライ&エラーがプログラマーには必要です。ある「使ってるものがよくわからない」問題はあまり起きず。完全な習熟にはそれなりに時間もかかりますので。HotDeployがスピードを呼ぶそう、単純にスピードを出すためのHotDeploy、に加えて、既存コード分析のためのHotDeploy、という役割が大きいなと感じるのです。HotDeployがなく再起動に30秒かかるシステムと、HotDeployがあるシステムとでは、トライ&エラーのサイクルスピードが断然違います。ディベロッパーのストレスにも大きく作用します。「インクリメンタル開発では圧倒的に多い」ということです。「作るものがしっかりと決まってる系の開発」では、HotDeploy無くてもいいかもなって。「なにを大切にするシステムなのか?」などを考慮しないとだなぁと。あればあるにこしたことはない、ってのは全くのその通りですが、それだとあまり費用対効果を絡めた議論ができなくなってしまうので、その「程度」をちゃんと分析しないとと思って。大きな方向性としてはこんな感じのセオリーが存在するってのをまとめてみたかったという感じです。そりゃぁ、スクリプト言語はこの辺強い!スクリプト言語の人から見れば、なに言ってんだ?って感じかもですね、当たり前の話ですから。「そりゃまあ」という感じかもですね。「こういった現場で発揮するパワーがある」って話は、jfluteがよく勉強会で話しています(^^。DB」というタイトルでいろいろ話します。いうことで、それはちょっと置いておいて...HotDeployを得るためには?コンパイル言語、というか、ここではJavaでHotDeployの環境を整えるためには、のお話。【Seasar】HotDeployというと、個人的にはやはりSeasar。「使い方を間違えなきゃ」有用です。失われてる...(人によってはすべてと言うかもしれません)使い方を間違ってるとHotDeployトラブルも多発します。明確にHotDeploy対象とそうでないもののパッケージを分けます。自動生成クラスはHotDeployにはしない。以下ブログでもうちょい詳しく書いています。「スマートデプロイとベタなものを分ける」のところ。jfluteが「Seasarどう?」って聞かれたら...http://d.hatena.ne.jp/jflute/20140324/seasarちょうど最近、まさしくHotDeployが効いてないSeasarを使ったプロジェクトでその辺を整備するチャンスがあって、HotDeployがしっかり効くようになりました!現場のエンジニアからは喜びの声を頂きました(^^。聞いているかぎりの評判はいまひとつ。そもそも完璧なHotDeployでなくてもよくって...「効く効かないの線引きがはっきりしている」ことが、とっても大切です。一文字だけ変えて再起動なんてこともざらですから、それだけでも「確実に効く」であれば有用かと。そのうち試してみますね。呼ばれる有償のツールもあるようです。Springでも難なくHotDeployできるようになったらめっちゃうれしーなーって切に思います。「ビジネス上の致命的なトラブルなのか、そうじゃないのか?」を判断するために、既存コードのスピード分析を必要とします。その判断は「ネ申重要」です。その判断を抜かして原因追及してはいけませんし、Webサービスであれば秒単位での判断スピードが求められます。二番目の行動とはいえスピードは落とせません。分析スピードは一秒...は言い過ぎにしても、10秒は大きな差です。極端な話、1分待つくらいなら、違い判断を下すっていうのもあるかも。現場のエンジニアは常にそういったプレッシャーと戦っているのです。彼らの精神的負担を減らしたいし、と考えるのです。安易にフレームワークを決めることはできないのです。キーポイントになりそうです。良いフレームワークだと聞いています。はやりましたが、jflute自身が実務で関わったことがないので、どういう感じで使いこなしていくと良いのかまだ不明です。アプローチするフレームワークの待ち行列に入っています。難しいですよね、この多様化の時代で抽象概念を使った論理を広げようとすると、ケースバイケースの罠にハマりやすいもので。......【追記】(2014/10/20)Seasarのこと、ちょっと書きました。Releasedあけましておめでとうございます。...2014-09-23URLマッピングは規約ベースベースがいいなWebフレームワークは星の数ほどあります。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。