jfluteの日記 このページをアンテナに追加

2016-09-26

DBFluteは10歳になりました

|

ものがたりのはじまりはじまり...

f:id:jflute:20160926153439j:image

2006年9月26日 ファーストリリース

ちょうど10年前、0.1.01 がリリースされました。

厳密には、それよりも前に DaoGen という名前で、
企業内でそれなりに利用されていましたが、
オープンソースとして誕生したのがその日でした。

そのときのソースコードがありますね。
もうすでに ConditionBean って感じですが、
SubQueryはずいぶんともっさりしてますね(^^
LdBookTest.java | Github

このときはまだ、S2Daoの自動生成ツールという
感覚でした。ConditionBeanはありましたが、
S2Daoだけだと足りないから追加しているみたいな。

ただ、どんどん改善していくうちに、
DBFluteらしさが前面に出てきて...

Seasarカンファで登壇登壇

[2007年5月27日]
Seasar Conference 2007 SpringDBFluteの紹介」
blog: Seasar カンファレンス 2007 | jfluteの日記
slide: PDF

そして、2007年10月頃です。
Seasarカンファでの出会いをきっかけに、
WEB+DB PRESS の執筆にも関わることができ、
DBFluteを6ページに渡って紹介させて頂きました。
これ読んで使い始めたというユーザーをたくさん耳にしました。
WEB+DBプレス!初執筆 | jfluteの日記

[2007年11月11日]
Seasar Conference 2007 Autumn
「現場ソリューション DBFluteblog: SeasarConf & 現場ソリューション振り返り | jfluteの日記
slide: PDF

[2008年5月24日]
Seasar Conference 2008 SpringDBFluteはどうなの?」
blog: Seasarカンファ2008 - DBFlute | jfluteの日記
slide: PDF

[2008年9月6日]
Seasar Conference 2008 Autumn
「現場ソリューション2 DBFluteblog: DBFluteセッション来場感謝! | jfluteの日記
slide: PDF

[2009年3月14日]
Seasar Conference 2009 WhiteDBFlute ライトニングConditionBean」
blog: Seasar Conference 2009 White The End | jfluteの日記
slide: PDF

[2009年6月13日]
Seasar Conference 2009 SpringDBFlute導入ポイント & MavenDBFlutePlugin」
blog: カンファとDBFluteユーザ集い無事終了 | jfluteの日記
slide: PDF

[2009年9月12日]
Seasar Conference 2009 AutumnDBFlute ライトニング外だしSQLblog: ライトニングの後... | jfluteの日記
slide: PDF

[2010年6月13日]
Seasar Conference 2o1oDBFluteのバージョンって今いくつ?」
blog: Seasarカンファレンス 2010 終了 | jfluteの日記
slide: (見当たらない...手元にもない...)

カンファ後のDBFluteユーザーの集い

Seasarカンファの後、食事会としての
"DBFluteユーザーの集い@神楽坂" をやっていました。

ここから色々な伝説も生まれたんですよね。
DBFluteユーザーはみなパワフルで、
毎回毎回大盛り上がりでしたね笑。

2008年5月のDBFluteユーザの集い @神楽坂SHUN・本家
2008年9月のDBFluteユーザの集い @(店わからず...)
2009年3月のDBFluteユーザの集い @うまい魚【海】
2009年6月のDBFluteユーザの集い @アッシジ
2009年9月のDBFluteユーザの集い @アッシジ
2010年6月のDBFluteユーザの集い @アッシジ

ブログのコメントでハンドルネームで参加表明して集まるって、
なかなか今考えるとすごいですね。
ほとんど初めてお会いする方ばかりでしたからね。
よく待ち合わせできたなーって(^^。

※2008年9月からは禁煙のお店で開催させて頂きました。
みなさん、ご協力ありがとうございます。

f:id:jflute:20160926134446j:image

2009年2月1日 S2Daoフォーク! 0.9.0

長らく S2Dao と共に生きてきたDBFluteですが、
S2Daojarファイルとお別れするときが...
allcommonをJARファイル化 | jfluteの日記

その頃、フォークって言葉は使っていなかったですが、
ApacheライセンスS2Dao のコードを、
新しく作ったDBFluteランタイム(jar)に取り込んで、
Seasarへの依存のないDBFluteに仕上がりました。

そもそもそれまでは、DBFluteランタイムに入っている
ようなクラスたち (例えば、CBスーパークラスとか)
もすべて自動生成されていました。
それらもVelocity管理されているので、
何かを変更しようとするとコストがかかりました。
業務DBに依存しないクラスたちなので、
本来はjarになっているべきものたち、
整理整頓してなんとかjarにまとめることができました。

OGNLも使うのをやめて、
IFコメントなどは自前でパースするようにしました。
ランタイムの依存は commons-logging だけに。

S2Daoへの依存を外すなんて想像もしてませんでしたが...
結局、そうなってしまいました。

2012年9月26日 SandBox卒業! 1.0.0

とうとう、1.0.0 をリリース!

DBFlute-1.0.0 Released | jfluteの日記

f:id:jflute:20120914162135j:image

0.9.x時代が長過ぎでしょ、
って感じですがようやくでしたね。
1.0.0 という名に恥じない品質で、
1.0.0 を出したかったというjfluteの思いが
あったからでした。

リリースパーティーも盛大にやりました(^^
出会いのDBFlute (1.0リリースパーティー) | jfluteの日記

中目黒レインボーバードランデヴーから、
お祝いのケーキも頂いちゃいました。
ありがとうございます。

f:id:jflute:20120929202151j:image

2015年1月1日 Java8版リリース 1.1.0

Java8ベースのバージョン 1.1.0 をリリース!

DBFlute-1.1.0 Released | jfluteの日記

奇跡的にハピネス・オン・ハイと「まったく同時に」
デプロイすることに成功しました。

f:id:jflute:20150101203736j:image
List<Member> memberList = memberBhv.selectList(cb -> {
    cb.setupSelect_MemberStatus();
    cb.query().setMemberName_LikeSearch("S", op -> op.likePrefix());
    cb.query().existsPurchase(purchaseCB -> {
        purchaseCB.query().setPurchasePrice_GreaterEqual(200);
    });
    cb.query().addOrderBy_Birthdate_Desc();
});
DBFluteの大きな転換でした。
Lambda前提のインターフェース、
Optionalのがっつり採用、
互換性を崩して次の時代に合わせた飛躍をしました。

恒例の元旦リリース

8年連続で元旦リリースしていますね...

2009年1月1日 DBFlute-0.8.8 Released | jfluteの日記
2010年1月1日 DBFlute-0.9.6.3 Released | jfluteの日記
2011年1月1日 DBFlute-0.9.7.8 Released | jfluteの日記
2012年1月1日 DBFlute-0.9.9.2C Released | jfluteの日記
2013年1月1日 DBFlute-1.0.1 Released @DisneySea | jfluteの日記
2014年1月1日 DBFlute-1.0.5B Released @DisneySea | jfluteの日記
2015年1月1日 DBFlute-1.1.0 Released @DisneySea | jfluteの日記
2016年1月1日 DBFlute-1.1.1 Released @DisneySea | jfluteの日記

さらに、DisneySeaの中でリリースを行う、
というのが恒例化しています笑。

f:id:jflute:20130101152618j:image

f:id:jflute:20130101145439j:image

まったく理由はないんですけどね。。。

f:id:jflute:20160101191242j:image

f:id:jflute:20150101205051j:image

...

2017年もやらないといけないんでしょうか?

独立イベント、DBFluteフェス

Seasarカンファも途絶えてしまいましたから、
DBFluteの独立イベントをやろう!と思い立ちました。
ビズリーチのみなさんの協力あって実現できました。
本当に本当にありがとうございます。

最初は、DBFluteフェスという名前じゃなかったんですね。
DBFluteユーザの集いが独立イベントになったという感じ。

2011年9月25日 DBFluteユーザの集い2011 | jfluteの日記

f:id:jflute:20110925122155j:image

2012年5月26日 DBFluteユーザの集い2012 | jfluteの日記

f:id:jflute:20120526134016j:image


...

そして、名前をDBFluteフェスに。
ここから2セッション方式になりました。
あっちでもこっちでもセッションロックフェスのように自由な参加スタイルで!

2013年10月19日 DBFluteフェス2013 | jfluteの日記

f:id:jflute:20131019131243j:image

...

2014年11月22日 奇跡のDBFluteフェス2014終わり | jfluteの日記

f:id:jflute:20141122180529j:image

Domaのnakamuraさんをゲストとして、
パネルディスカッションをしました。
新しい試みのフェスでした。

...

2015年11月21日 笑顔のDBFluteフェス2015終わり | jfluteの日記

f:id:jflute:20151121125626j:image

1000円取る方式、いきなり懇談会方式、
チャレンジ過ぎる企画にも関わらず、
大勢の方に来ていただきました。

...

そして、今年も!?

LastaFluteなんてものも

DB周りだけではなく、Webフレームワークにも
手を出してしまいました。LastaFluteです。

だいぶ無茶してしまいましたが...
さすがに「ワーク"ワークのためのライフ"バランス」考える | jfluteの日記

f:id:jflute:20150726203423j:image

でもでも、
喜んでくれる人がいるので、やって良かったです。

LastaFlute First Impact | Speaker Deck

そして、
まだまだ冒険ですね...

最後最後のSeasarカンファ

久しぶり復活のSeasarカンファで、
Seasar/SAStrutsをフォークした LastaFlute を公表しました。
どーん!2015年9月26日です。

LastaFlute in Seasarカンファ | jfluteの日記

f:id:jflute:20150926150508j:image


...
...
そして...2016年9月24日

Seasarカンファレンス2016 Final | jfluteの日記

f:id:jflute:20160924161016j:image

ある意味で、DBFluteは本当に帰るところがなくなったと言えるかも。
しっかり DBFlute で生きていかないとですね。

出張勉強会もやるように

招待されて (or 自分からお願いして)、
様々なところで講演する機会を頂きました。

仙台でのDBFluteショー | jfluteの日記
DBFlute出張講演会あっとアットウェア | jfluteの日記
ClubDB2でDBFlute語り | jfluteの日記
ウルシステム's DBFlute | jfluteの日記
u-next DBFlutist | jfluteの日記
JPOUGに登壇させていただきました。 | jfluteの日記
リクルートテクノロジーズさん's DBFlute | jfluteの日記

大阪で開催された "わんくま同盟" でも講演させて頂きました!
(ごめんなさい、ブログ書けてない...)

DBFluteではないですが、
CROSS2016にもお誘いいただきました。
RDB界のそうそうたるメンバーの中に混じって、
jfluteもパネラーとして参加させて頂きました。

最近のRDB四方山話 | CROSS2016

相談していただければ、
DBFlute語りに飛んでいーきまーすよー♪

関連プロダクトも増えたよ

DBFluteに加え...

o EMecha (Eclipse Plugin)
o DBFlute Maven Plugin
o DBFlute Intro

o DBFlute Hamcrest
o UTFlute

o Lasta Di
o LastaFlute
o MailFlute
o TomcatBoot
o JettyBoot

DBFluteを広めるために、
DBFluteと連携をするプロダクトを作らないと
いけないと思ったんですね(若干後付け)。

※協力頂いているコミッターのみなさま、
本当にありがとうございます。

...

あと、DBFlute.NET も忘れてはいけません。

C#プログラマーのユーザー、確実にいらっしゃいます。
なかなか着手できないジレンマがありますが、
使ってくれる方がいらっしゃる限り、
なんとかしたい気持ちはずっと持っています。

...

そして、まだ道半ばですが、Scala版も暫定開発しました。

DBFlute on Scala | DBFlute

まだ、Scalaという世界観で、
DBFluteらしさをどう表現したらいいのか?
迷うところがたくさんあるのですが、
勉強にもなるので薄く長くアプローチしていこうかなと
思っています。(ユーザー全くいないし)

jfluteも成長したよ

なんといっても、
これだけのオープンソース活動をやってきたことで、
ずいぶんといろいろと鍛えられました。

まだまだ足りないところだらけですが、
ぜんぜんプログラマー自信のなかったjfluteだったのですが、
なんとかやってきただけのことはできるようになってきました。

とにもかくにも、行動することですね

...

DBFluteのフォローイング、アドバイザリーなど、
DBFluteにまつわること、DBFluteがきっかけで
仕事がもらえるようになってきました。

個人オープンソースプログラマーのジレンマ、
"オープンソースではなかなか食べていけない"
(少なくとも自分で作ったオープンソースでは)

自分は、そこに対してチャレンジをしている
真っ最中と言えるでしょう。

f:id:jflute:20160926130612j:image

時が経つのは速い?遅い?

遅い! 

1年前の自分やDBFlute,
3年前の自分やDBFlute,
5年前の自分やDBFlute,

全然違いすぎる。
思っていることも考えていることも、
気にしていることも気にしているものも、
ノウハウや視点も、環境も状況も...

まだ1年しか経ってないの?
まだ3年しか経ってないの?
まだ5年しか経ってないの?

って、思えるのです。

あまりに色々とありすぎて...

だから、

1年後の自分やDBFlute,
3年後の自分やDBFlute,
5年後の自分やDBFlute,

って考えると、
全然違うんだろうなぁと。
めちゃ不安だし、わくわくします。

いつまでこんなことやってるんでしょうか?

...


細かいところでたくさん色々と失敗して、
いま思い出しても「どしーん」とへこむこと、
たくさんありますが...

それでも!

この10年間 DBFlute に注ぎ込んできて、
後悔はないですね

まあまだ冒険の途中だから後悔のしようがないのかな。
また後でゆっくり考えましょうか。後悔するかしないか。

なので、とりあえず、
今まで通り反射神経で行動していきます(^^。

DBFlute, Happy Birthday!

f:id:jflute:20160926122956j:image

mokkouyou2001mokkouyou2001 2016/09/28 14:37 感謝やらなにやら伝えたいことはたくさんありますが、
シンプルに

10周年おめでとうございます。
次の10年もよろしくお願いします。

2016-09-24

Seasarカンファレンス2016 Final

|

行ってきましたー!

終わったー!

f:id:jflute:20160924123336j:image

Seasarカンファレンス2016

に行ってきました。
そして、しゃべってきました。

自分はずっとメインホールにいたので、
そこでの内容だけで。
(ぶっ通しで裏番組のはぶさん、お疲れ様です(^^)

一時間目、ひがさんより

「SeasarProjectふりかえり」
 by ひがさん

f:id:jflute:20160924130242j:image

まずは、Seasarに多大なる貢献してくださった
お二人の感謝式。

インフラのふたがわさん!

f:id:jflute:20160924130313j:image

そして、はしもとさん!

f:id:jflute:20160924130351j:image

ぱちぱちぱちー

...

そして、ひがさんからSeasarProjectの振り返り。

f:id:jflute:20160924132024j:image

Seasar, S2Dao, S2JSF, Teeda,
SAStruts, S2JDBC とひがさんがどういう思いで、
どういうニュアンスで作られてきたのか?
というのが、赤裸々に語られててとても参考になりました。
こういう話を聞くって大切ですよね。

本当にありがとうございました。

二時間目、jfluteより

「Seasarのフォークの仕方、LastaFlute編」
by jflute

なぜかメインホール!(><。

f:id:jflute:20160924141044j:image

実際は、LastaFlute編というより、
Lasta Di編でしたね。

f:id:jflute:20160924141925j:image

最後、やはり Seasarソースコードを出す
セッションをやりたかったという思いがありました。
ちょうど、Lasta Diの開発話をすれば、
Seasarの技術的な話でもあり、
Lastaの紹介にもなるかなと思って。

f:id:jflute:20160924142008j:image

なんとか、LastaFluteDBFlute知らない人でも
楽しめるようにしたつもりではあります(^^。

...

そうだ、
これはセッションで紹介するチャンスなかったけど、
SAStrutsの一気通貫図を描きました。
web.xmlからActionが呼ばれるまで。
コードリーディングするときに地図として使えるようにと。
 => SAStrutsのAction一気通貫図

三時間目、せらさんより

「SAStruts + S2JDBC から
Skinny Framework への移行ガイド」
by seratch

f:id:jflute:20160924150154j:image

SAStrutsチュートリアルを
Skinny Framework で作り直してみたという、
なかなかの手間のかかりよう、すごい!

普通にScalaのお勉強になりました。
Atom良いですね。
Scala書くときそっちのほうがいいかも
とか思っちゃったので今度試してみようかなって(^^。

f:id:jflute:20160924155427j:image

"C" はなかったんですけど、
なんとか "U" を横にして...笑

四時間目、jfluteより

DBFluteがどれだけSeasarにお世話になったことか」
by jflute

なぜかメインホール!(><。(二回目)

f:id:jflute:20160924161016j:image

本当は、ぼくは端っこの小さな部屋で、
DBFluteユーザー相手にしゃべろうと思っていたのですが、
まあ全体の来場者数と会場のバランスからか、
二回ともメインホールになりました(^^。
「jfluteって誰だよ、DBFluteって何?」
って方も多かったかもしれませんが...

f:id:jflute:20160924164702j:image

Seasarという存在をきっかけに、

o プロダクトも仕事もプライベートも影響されている
 オープンソースプログラマーがいるということ
o そういうプロダクトがSeasarにあるということ
o しかもいまなお冒険しているということ
o その冒険の中で、Seasarソースコードが
 形を変えて生き続けているということ

それが伝わればいいかなと。
このセッションは、本当に会場に来て、
聞いてくださった方々のためだけに。
ここまで赤裸々と語ることもめったにないでしょう。

f:id:jflute:20160924165048j:image

気になる方は参加された方に聞いてください(^^。

LT大会です!

楽しいLT大会でした!
はしもとさんの無茶振りにも関わらず、
みなさん素敵なセッションでした(^^。

f:id:jflute:20160924171212j:image

f:id:jflute:20160924172503j:image

(写真が足りなくてごめんなさい)

Seasarサポート終了でどうすれば?

これはちょっと事務的なお話し。

これからも話題になると思うので、
とりあえずjfluteの見解はこちら。
 => jfluteが「Seasarサポート終了どうすればいい?」と聞かれたら...

この話を振られたら、
「まずこのブログを読んでください」
から始まる感じですね(^^。

Seasar.NETのトマト

Seasar.NETの元リーダーで、
DIコンテナ "Quill" の作者の、
id:sugimotokazuya さんのトマト!
 => はるひ畑 -トマトつくってます-

f:id:jflute:20160924174731j:image

昨年に引き続き今年もカンファレンス会場に
持ってきました。
合わせて前日に送ってもらいました。
ありがとうございます!

カンファレンス終わった直後にDBFluteユーザーで
集まってパクパク食べていました。
このトマトは本当に美味しいトマトです!

DBFluteユーザーの集い

Seasarカンファの裏恒例の
「DBFluteユーザーの集い」
少人数ながらもやりました。

f:id:jflute:20160924185701j:image

単なる食事会なんですけど、
この食事会からも色々な伝説が生まれましたから。
思い出の神楽坂でみんなで話をしてきました。

f:id:jflute:20160924185707j:image

...

そう、
なつかしい...

DBFluteユーザーって、
18時から23時までずっとしゃべりっぱなしで
技術話でひたすら盛り上がるんですヨゥ笑。
しかもとても高度だし問題意識が強いしおもしろいし(^^。
ぜんぜん勢い止まらないから、ぼくが、
「みんなそろそろお店おしまいだからしめるよー」
「JRの人こっちー、新宿に帰る人はー...」
ってやってたような笑。

ぼくは何度も何度も、
「なんで、ぼくよりも遥かに優秀な人たちが、
ぼくの話を聞きに来てくれるんだろう?」
って思って、その度にモチベーションが上がって、
また次のカンファまでの実装パワーになっていました。

「DBFluteを作る...
ということだけが、自分にできること」

そんな思いにさせてくれた
"集いという名の単なる食事会"
でした。

すごい人と会えたSeasarカンファ

ひがさんとは、
今までもお会いしたことはあるのですが、
じっくりとお話させて頂いたのは今日が初めて!?
と言っても過言ではありません。
あまりそういう機会がありませんでした。
今日、とても興味深い良いアドバイスを頂きました。
色々とお礼も言いたかったので、嬉しかったですね。

Seasarに関わっていたとはいえ、
DBFluteという独自路線をずっと歩いていた自分。
あまりSeasarのコミッタ同士での交流は少なかったのです。
(懇談会もDBFluteユーザーの集いと独自でしたし)

それだけに今日は色々な人とご挨拶ができて、
色々な人の前でお話をすることができて良かった!

Seasarカンファでたくさんの人と出会いました。
もうあまり出会う機会のない方もいれば、
いまもガンガン交流している方もいます。
みんなとにかく "すごい人ばかり" で刺激になります。

Seasarカンファ、本当にありがとう。
そして、法政大学、外濠校舎、ありがとう。

f:id:jflute:20160924174236j:image

何気のこの場所に来ることがもうないってことが、
一番寂しいことかもですね。

さて、次はDBFluteフェス!

Seasarカンファレンスはもうおしまいのようです。
でも、

SeasarS2Daoソースコードを利用して、
デザインし直されたプロダクトたち

のイベントは、これからもあります。

毎年恒例の「DBFluteフェス」がやってきます。
昨年のフェスの模様がこちら:
 => 笑顔のDBFluteフェス2015終わり

11月27日(日)を予定しています。
場所はいつものビズリーチのガーデンにて。
詳細は全く決めていませんが、
日付だけ確定したのでここに記しておきます。

オープンソースですから...

良いものであれば形を変えて生き続ける

可能性があります。
そんなことを伝えたかった一日でした。

本当にありがとうございました。

2016-09-21

jfluteが「Seasarサポート終了どうすればいい?」と聞かれたら...

|

とにかく聞かれます

今年一年、色々な人から...

プログラマー仲間で軽いノリで聞かれることもあれば、
出先の現場の技術者やマネージャーの方から相談されることも。
程度の差はあれど、
jfluteの立場的に聞かれることがとても多いです。

今までもTwitterブログでも似たようなことは
話してきましたが、今後も多いと想像されるので...

"jfluteの考え"

今まで質問されてアドリブで回答してきたことを、
ちょっと整理整頓してまとめておきたいなと。

何を心配していますか?

さて、Seasarサポート終了ということで、
何を心配されていますでしょうか?

A. 使い勝手が向上していかない
B. MLで質問しても返事が帰ってこない
C. バグ脆弱性が出ても直らない
D. ソースが爆発して動かなくなる
A. 使い勝手が向上していかない
すでに5,6年前から、
大きな改善はあまり行われておりません。

厳密には1年ごとにリリースはされていましたが、
ちょっとした改善が主な内容です。
(それはそれでありがたいものですが)

そして最終リリースは 2014-12-07 の 2.4.48,
そう、2年近くリリースされていません。
(ブログ執筆時点)

なので、
"9月27日から使い勝手が向上しなくて困る!"
って話ではなく、
すでにもう数年前からその状態だったと言えるでしょう。

そこ気にしてなかったのであれば、
少なくとも9月27日を強く意識する必要はないでしょう。
B. MLで質問しても返事が帰ってこない
Seasar-userメーリングリスト
 => Seasar-user 保存書庫

は、もともとユーザー同士の情報交換の場です。
コミッターも含まれていますが、
コミッターもユーザーの一人という感覚です。

9月27日からMLに投稿して完全に無視されるかどうか?
実際にはわかりませんが、ユーザー同士でコメントができる
ものであれば返事はある可能性は高いだろうし、
単にどのユーザーも答えられないものであれば、
返事はないだろうし。
別に9月27日が境目で返事が来る来ないが
ガラリと変わるわけではないでしょう。

まだまだ使っているユーザーが多いのであれば、
MLだけでなく、情報交換できるチャンスは
いくらでもあるかと思います。
C. バグ脆弱性が出ても直らない
9月27日以降だったら必ず直らないのか?
これもわかりません。

一方で...

9月27日より前だったら必ず直っていたのか?
そうとも思いません。

ボランティア精神で成り立っているオープンソース活動ですから、
それが迅速に、かつ、必ず直っていたという保証もありません。

Seasar-2.4はすでに互換性を重視したフェーズに
入っていたので、あまり問題にならないものであれば、
回避情報だけ提供して本体には手を入れない、
って判断もあり得るかと思います。
(実際そういうのあったかもしれません)

もし、致命的な脆弱性が発生したとして、
仮に本体は直らなかったとしても、
まだまだたくさんいるユーザーの方々から、
Twitterブログなので回避方法などの情報が
回ってくる可能性も高いでしょう。

また、脆弱性を直したプルリクを送る人もいるかもしれません。
オープンソースですから、みんなで直せるのです。
D. ソースが爆発して動かなくなる
そんなことはありません笑。

良し悪しありますが、
Javaは互換性を重視している言語なので、
ずっと昔に作られたフレームワークであっても、
正常に動く可能性が非常に高いです。

実際にうまく動いているなら、
問題なく利用することができるでしょう。

心配事があるならすでに遅い

Seasarのサポートに対して心配なことがあるとすれば、
すでに数年前からその心配はあったと言えるでしょう。

別に9月27日から心配が始まるわけではありません。
9月27日から心配するのは "すでに遅い" と考えます。

...

ちなみに、
Seasarを使っている現場で多く利用されているだろう
と思われる Log4j のバージョン 1.x ですが、
すでにサポートが終了しています。
 => Log4jバージョン1のサポートが終了 | InfoQ

そもそも、多くの人が利用されてると思われる、
Java6 や Java7 ですが、こんな感じです。
 => Java 7とJava 6の今後について | Oracle Blog

Seasarだけ心配しててもしょうがないでしょう。

最新版使っていますか?

また、Seasarの最新版を使っていますでしょうか?
最新版は、2014-12-07 にリリースされた 2.4.48 です。
(ブログ執筆時点)

それなりにバグ修正や改善などが施されています。

MLに質問や相談などする場合、
最新版でないと、コメントする方もやりづらいです。

何か本体に重要なバグ脆弱性の修正あった場合、
最新版でないと、迅速に適用するというのもやりづらいです。

最新版を使ってないというのは、
9月27日より前のサポートも享受していないと言えます。
これからどこかにサポートを探してお願いするにしても、
最新版でないとそのサポートを享受しづらい状況と言えます。
でも、多くの現場で最新版を使ってないのをよく見かけます。

Seasarのサポートを心配するのであれば、
まずは最新版に上げるところから始める必要があるでしょう。

フレームワークサポート業務の難しさ

どこか第三者の企業にサポートをお願いする
という話が、ときに浮上します。

もちろん、してくれるところがあればいいですし、
そうやってフレームワークにちゃんとお金を払っていく、
という姿勢はとても嬉しいことです。

でも、なかなか難しいだろうと思っています。
サポート業務で儲かるためには?
ひとつ、フレームワークのサポート業務、
で儲かっているという話を聞いたことがありません。

そもそもサポート業務は、
いつどこでどういう質問や要望が来るかわかりません。
普段から、ある程度の時間の余裕を確保しておかないと
いざってときの対応ができませんし、
フレームワークインプットの時間も必要です。
(Seasarに詳しい人だとしても、
いまやっている仕事では別のフレームワークを
使っているって人も多いでしょうから)

逆に、そうしないと、別の仕事が忙しくて対応できないとか、
その場でフレームワークインプットすることになって、
対応に時間がかかってしまったりしてしまいます。

フレームワークのサポート業務をやるような人は、
おそらく優秀な人でしょう。給料も高いでしょうし、
それ以外の仕事も、色々な現場から高い単価での
オファーが来ていることでしょう。
その人に時間の余裕を与えることは会社の機会損失です。

なので、もし一社だけのサポートだと、
すごく高い値段になってしまいます。
一社のために、優秀なエンジニア機会損失を
発生させることになりますから、
その分の値段を乗せないといけないから。

例えば、週5日で別の仕事をやっていたとして、
サポート業務を与えるとなると、
いざってときの時間の確保とインプットのために、
その別の仕事を週4日に減らさないといけないかもしれません。
すると週1日の分の単価がサポート代金に反映されます。
優秀なエンジニアの週1日はそれなりに高いです。

なので、通常サポート業務は、
何社ものサポートを同時に受注して、
専任にさせることで時間の余裕を確保し、
うまくノウハウを再利用して効率性を高めて、
うまく儲けられるようにすることが求められます。

ですが、うまくSeasarのサポートで、
何社ものサポートを受注できる体制にある会社は
なかなか多くはないでしょう。
(また、それをやりたいと思うところも少ないかも)
サポートのスコープは?
ふたつ、サポートのスコープを決めるのは難しいこと。

o 判明したバグ脆弱性を必ず直す保証をする?
o バグ脆弱性かわからない現象の質問を受け付ける?
o どのライブラリが対象?

<< 判明したバグ脆弱性を必ず直す保証をする? >>
そもそも9月27日より前だって、
必ずバグ脆弱性が直っていた保証はありません。
自分たちが作っていないフレームワークを、
なかなか「必ず直す」という保証を低価格で受け持つのは、
なかなか難しいでしょう。
実際には、回避策を一緒に考える、
というような業務支援が現実的なところかと思います。

<< バグ脆弱性かわからない現象の質問を受け付ける? >>
バグ脆弱性かわからない段階での、
発生した現象の質問を受け付けるとなると、
結局現場での使い方や現場の業務仕様などを知らないと、
判断ができないことが多々あります。
結局、リモートだとメールで何度も何度も
やりとりをすることになり、あまりスピードは出ません。

<< どのライブラリが対象? >>
Seasarは様々なライブラリに依存しています。
Seasar本体だけなのか?依存ライブラリも含めるのか?
依存ライブラリも含めると非常に複雑になります。
サポート料金は跳ね上がることでしょう。
かといって依存ライブラリを外したとしても、
グレーゾーンが多いので実質調査するときとかは、
意識しないといけません。

そもそもSeasarだけでも複雑です。
なのでいっそ、
脆弱性が発生した時に致命的になりやすい
Web周りのフレームワークだけということで、
"SAStrutsだけサポート" ならまだ現実的ではないかと。

などなど、
こういうのを決めるだけでずいぶん時間もかかるでしょう。
これもやはり何社ものサポートを受けることができれば、
この辺のノウハウが再利用できて効率的になるでしょうが、
一社だけスポットで、とかになるとなかなか厳しい値段に
なるかと思います。
希少性の金額を出せる?
といったもろもろから、
"希少的な案件" になるので、
実際に思い描いているサポート料金よりも、
高い値段になりやすいと考えます。

それでも払う判断をするかどうか...
"別のことに使った方がいいのでは?"
という考えも浮かんでくるでしょう。

オープンソースモチベーション

そもそも、
「Seasar本家にサポートを続けて欲しい!」
と思うのであれば...

オープンソースですから、
コミッターがサポートしてくれるかどうかは、
コミッターのモチベーション次第です。

ユーザーが多くのフィードバックをしたり、
「Seasarを便利に使っている」ということを
もっと露出することで、
モチベーションは上がってきます。

通常、コミッターとユーザーに金銭関係はありませんから、
"ただ密かに使っているだけ" では、
あまりコミッターの得にはなりません。
厳密には使っているだけでも嬉しいこともありますが、
とはいえ、極端な話フリーライドに近い状態だと言えます。

Seasarは募集していないかもしれませんが、
"寄付する" という選択肢だってあるでしょう。
例えば、jfluteはEclipseに寄付しました。
 => Eclipseに寄付しました | jfluteの日記

そういった動きが出てくることで...

またコミッターのモチベーションが復活して、
サポートを続けるってこともあるかもしれません。

別の人が「コミッターになりたい!」と言って、
サポートを続けるってこともあるかもしれません。

サポートが終わったからといって、
"必ずサポートを終わりにしないといけない!"
わけでもありません。
コードが公開されているわけですから、
「サポートしたい!」という人がいれば、
それは全然アリなわけで。

オープンソースですから、

みんなで盛り立てていけば盛り上がるのです

ユーザーの行動次第です。
でなければ、単に何も起きないだけです。

という分析からのまとめ

というjfluteの分析から...

ひとつ、

そもそも今までのサポートを享受してないのであれば、
9月27日から極端に何か変わるわけでもないので気にしない、
何かあればSeasar-userメーリングリストに投げる

要は、別に今までもあんまり気にしてなかったんであれば、
これからもそんなに気にしなくてもいいんじゃない?
って感じです。

何か特別に聞きたいことや相談や要望があれば、
ぜひ、Seasar-userメーリングリストに投げてみましょう。
ユーザー同士で何か情報交換できるかもしれません。

実際に、jfluteの身の回りの現場ではそんな感覚です。
それよりも、早く Java8 にアップグレードしないと!
そっちの方が優先課題です。
Java6では動かないライブラリも出てきました。
そのうち、Java7では動かないライブラリも出てくるでしょう。
Javaのバージョンが古いままの方が実害が遥かに大きいです。

...

ふたつ、

サポートを探すよりも、自分たちで直せるようにする、
外部の力を借りるなら、それを支援してもらう方がいい

なんといってもオープンソースですから、
そもそも何か心配なことがあれば、自分で直せます。

サポートに高いお金を払っても、
それは自分たちのノウハウになりません。
それよりも、社内の見込みのありそうなエンジニア投資して、
何かあっても自分たちで対応できるような体制作りに
お金を使った方が建設的だろうと考えます。

どうせ外部にお金を使うのであれば、
外部の優秀なエンジニア勉強会をお願いしたり、
技術支援のサポートをお願いしたりする方が、
ちゃんとノウハウが社内に残るのでその方が
持続的なメリットになるかと思います。

単なるサポートだと、単にお金が出ていくだけ、
何もノウハウが社内に残らない可能性ありますし、
サポートする会社がずっとサポートを続けるとは限りません。
持続的な体制を作っていかないとジリ貧に陥る可能性があります。

...

みっつ、

どうしても外部にサポートを求めるなら、
ユーザー同士でまとまってサポートをお願いする

スポットで一社だけ相手にサポートするという会社は、
探してもなかなか見つからないでしょう。
すでに述べた通り、やりづらい理由がそれだけあるからです。

サポートする会社がちゃんと儲かる仕組み、
これを作り出せないとうまく回らないですし、
仮にサポートしてもらったとしても長持ちしないでしょう。

ちなみに、ユーザー同士でコミュニケーションを取って、
互いにサポートし合うというのもアリですね。
とういか、
その場がまさしくSeasar-userメーリングリストと言えます。

...

よっつ、

そもそも、Seasar本体のサポートを続けて欲しいなら
ユーザーからどんどんSeasarへの貢献を

フリーライドが必ずしも悪いわけではありません。
フリーライドから貢献する人に変わることもありますし、
フリーライドの方々によってシェアの土台ができて、
それが活動のためのパワーになることもあります。

ポイントは、
フリーライドする人たちと貢献する人たちの割合の問題です。
(サービスだと、無料会員と有料会員の割合に置き換えられるでしょう)

無料でコミッターに明確な利益を与えずに使っているわけですから、
何も行動しなければ、放っておけば、こうなるのは当然です。

まあサポートが終わった原因は、
そういうこととは無関係かもしれませんが...
(そこはSeasarコミッターの方のブログを参照)

もし仮に、

o たくさんのユーザーが「Seasar便利だ」と露出していたら
o たくさんのユーザーが「Seasarに寄付」などの支援をしていたら

もしかしたら、
サポートは終わってなかったかもしれません。
別のコミッターが引き継いだかもしれません。
新しいコミッターが出てきたかもしれません。

もし、今からでもサポート復活を切に願うのであれば、
そういった活動をユーザー主導でやっていく他ありません。
そもそも、コミッターとユーザーに垣根はありません。

思い切って社内のエンジニアをコミッターにするなど、
様々な支援の形が想像できます。方法はいくらでもあります。

jfluteの思い

jflute個人的には、
すでに、Seasar をフォークした Lasta Di,
そして、SAStruts をフォークした LastaFlute を作り、
身近な現場ではそれで回っています。
どんどんそちらを盛り立てていこうと考えています。

なので、Seasar本体のソースコードに対して、
何をアプローチをすることはあまり想像できませんが、 
現実リアルタイムで使っている現場もありますので、
ちょっとずつLastaへの移行を促しながらも、
何かあればコードを読んで調べることはあるでしょう。
まあ、SAFlute や DBFlute を利用している
ことがほとんどなので、それの延長のような感覚です。

今週末のSeasarカンファレンスに登壇してきます。
 => Seasar Conference 2016 Final | Connpass

そして、Seasarについて語ってきます。
感謝の気持ちを込めて。
 => えむさひこくぼ | SeasarConf

...

そもそも、
企業が提供しているわけではないオープンソースにおいて、
"サポートが続く続かない" という話自体に、
あまり意味がないと考えています。
コミュニティ個人オープンソースは、
売ってる商品と違って、

コミッターとユーザーのコラボレーション

で成り立つものですから、
極端な話、
行動すればどうにだってできる可能性があるわけです。
逆にコミッターだけでどうにかできるものでもなかったり。

DBFluteでも時々聞かれますが、こんな感覚...

サポートを終了する保証もできないんです

仮にサポートを終了して、そして要望が来たとして...
でもやっぱり時間があったらやっちゃうかもしれないし。
嬉しい言葉も一緒だったら勢いで無理しても
対応するかもしれないし(^^。
しれーと「新しいバージョンをリリースしました!」
とかってブログ書くこともあるかもしれません。

逆に、いまサポートしてる状態と定義したとしても、
要望やバグ修正を必ず対応できる保証だってないですし。
それをサポートと言えるのかどうか?

単に、今まで十年間、

体力と精神力、時間と生活資金の許せる範囲内で、
ユーザーと共にjfluteがアドリブし続けてきた!

ってだけで、
サポートしてきたっていう感覚はないのです。
サポートを終わりにするどころか始めてすらいない。
(むかしはこんな深く考えてなかったので、
サポートという言葉を曖昧にしたまま、
するしないって話をしたこともあったかもですが、
いま考えるとこんなニュアンスですね)

だから、
「DBFluteのサポートは続けるんですか?」
って聞かれたとしても...

「どうして欲しいですか?」
って聞き返して相談してから考えることだし、

「どういう意味合いでのサポート?」
って踏み込まないと返事ができないのです。

...

何かもっとSeasarに対して強いサポートを求む、
って相談されたら、どちらかというと、
ソースコードリーディングなどの勉強会など、
"現場がSAStrutsに詳しくなっていくための支援"
をしてくれる人を探すことを真っ先に提案するでしょう。
その理由は、ここまでブログで綴った通りです。

「将来、別のフレームワークを採用するから、
SAStrutsに詳しくなっても役に立たないのでは?」

そんなことはありません。
フレームワークのコードを読んで理解することで、
新しいフレームワークを理解するスキルも身についてると言えます。
どこかの将来、また別のフレームワークで役に立ちます。

なので、どうせなら、

そのノウハウを現場に積み重ねていく

という方向性で進めていく方が、
現場のためになると考えるのです。

f:id:jflute:20160921143509j:image

2016-09-12

レビューしやすいコード (Reviewable Code)

|

れびゅーわぶる!?

レビューしやすいコード

よく、jfluteが現場で掲げるコーディングテーマです。
主に、事業会社でのサービス開発における、
スタートアップの時期から少し経ってチーム開発し始めた、
インクリメンタル開発が続いてきた時に適用します。

色々とたくさんは言わず、
とにかくこれだけは心がけよう、
とディベロッパーにお願いしていることです。

インクリメンタル開発に大切なこと

インクリメンタル開発の現場をデザインする上で、
大切にすべきことが大きく二つあります。
ビジネス貢献の向上
もうさすがに言わずと知れたことですが、
事業会社ではビジネスとプログラミングが非常に密接です。
ディベロッパーもアーキテクトもビジネス貢献を忘れて、
的外れなものを作っても自分が苦しむだけです。

スタートアップインクリメンタル開発の特徴が
よくわからない方は、こちらの資料がオススメです。
 => LastaFlute First Impact | Speaker Deck

ビジネスと言うと少し大げさに思われる方は、
そこを "問題解決" と置き換えてもいいでしょう。

ビジネスを成功させるためにどうしたらいいか?

ディベロッパーが対峙している課題は、
そこから距離はちょっと遠いものではありますが、
ぼくらはそこに頭をひねって、
間接的でつながりを考える必要があります。

# 本来、ここだけでたくさんのお話があるのですが、
# 今日の焦点はここではないので割愛します。
# このビジネス貢献の向上を下支えする要因は何か?
# そこに焦点を当てていきます。
プログラミング環境の向上
事業会社での技術課題は非常に多様的です。
エンジニアの技術追求の意識も求められます。
優秀なエンジニアに来てもらうことも大切ですし、
優秀なエンジニアに長くいてもらうことも大切です。
(どうしても人の入れ替わりは激しいものです)

いくらビジネスへの意識を高く持ってもらったとしても...

根本のプログラミング環境が乱れていると、
ビジネスへの意識をキープできないのです

これは、マズロー欲求と似ているかもしれません。
高次の欲求は、低次の欲求の上に成り立っています。
"本質的でないことに時間をかかるような現場" だと、
モチベーションは下がります。
そして、高次の欲求までたどり着けないのです。
 => エンジニアのモチベーションを下げる方法 | jfluteの日記

単純に、ディスプレイや椅子などのわかりやすいものから、
開発環境の充実、そして、コード上でのスムーズな立ち回り、
これらがポイントになってきます。

ただでさえ人の入れ替わりの激しい現場、
そして特にいま (2016/9現在) の売り手市場、
高い技術課題を解決できる人に現場にいてもらい、
そして、その人に高いビジネス意識を持ってもらい、
有益な成果を出してもらうためには、
低次の欲求をしっかり満たすことが前提です。

そう、

ビジネス貢献とプログラミング環境の向上は、
密接につながっている

のです。

コードの乱れが生むもの

さて、コードが乱れていると、
何が起きる?
デメリットの連鎖
インクリメンタル開発は、
非常にコードの乱れが発生しやすい現場です。
そして、その乱れのデメリットをもろに食らいやすい現場です。
人の入れ替わりがそれを発生させるし、
それが人の入れ替わりを発生させます。

短期的: 長いレビュー、バグの見逃し、緊急リリース、手戻り
中期的: 長い既存コード分析、メンテナンスモチベーション低下
長期的: システム再構築or非効率メンテ、優秀エンジニアの離散

短期的デメリットの対応を誤ると、
中期的デメリットが顕在化してきます。
中期的デメリットは対応しづらく、
積み重ねると長期的デメリットになります。
短期的デメリットのストーリー
読むのもつらい把握しづらいコード、
レビューは長くなり、
レビューワーの負荷も高くなり、
バグは見逃し、緊急リリース...

スタートアップ直後は、
ビジネス規模もシステムの規模も小さく、
緊急リリースのコストは低いですが、
インクリメンタルで積み重なってくると、
気軽にリリースも少しずつできなくなってきます。
ちょっとした修正でも、
緊急リリースに奪われる時間が増えてきます。

また、レビューでの見逃しが発生すると、
リリースしてから、
「実はそういう実装じゃないほうがよかった!」
と判明して手戻りコストが発生したりもします。

中期的デメリットのストーリー
そして、様々な負のパターンも生み出し...
 => メンテ不能の強者、引数リモコンパターン | jfluteの日記
 => ルーズなDaoパターンなら見たくない | jfluteの日記

気づいたら、
ちょっとしたこともすごく時間がかかるようになって、
なんだか働いてるわりには先に進んだ感が出ない...
「なんか、この現場のコード直すお仕事、いやだなぁ...」
メンテナンス意欲が下がり、別の仕事したくなってきます。

一方で、それに明確に気づかないのも問題です。
ある日突然足が重くなるわけじゃなく、
徐々に徐々にそうなっていくので慣れてしまうのです。
一年前と正確に比べるのは難しいことです。
効率悪いのに効率悪いと思わないでずっと...

人もどんどん入れ替わっていくので、
初めて来た人はなおさらわからない。
それに気づくのは優秀なエンジニアだけ。
でも解決は困難。
チームの問題意識がバラバラだから。
長期的デメリットのストーリー
最悪の長期戦へ。

「これ作り直そうよ!」
しまいには、システムの再構築という、
大きな代償を会社が払うことになります。
でも、そんなコストを払えるか?
そのためにビジネスを止められるか?

なかなかできません。
そこで続くのは非効率メンテ、しかも長期化。
優秀なエンジニアは敏感なので、
どんどん立ち去っていきます。
様々な理由を見つけて現場からいなくなります。

すると逆に、
「やっぱり、再構築やろう!」
と英断したところで、現場にスキルが足りず、
再構築プロジェクトを進めることもできません。

両方だいじなんです

一方で、例えば "レビューが長くなる" からと言って
レビューせずにリリースをすると、
早くリリースできた!と思って短期的に喜んでいたら、
実は中期的デメリットを生み出すことになります。

しかしながら、
コードの乱れでレビューが長くなることによって、
レビューワーのレビューに対する心理的重荷が発生します。
なので、自然とレビューに対して非消極的な対策をする
空気になっていきます。これは一つの罠と言えるでしょう。

安易に逆サイドに振れる対策を取ると、
行ったり来たりを繰り返すことになります。

なぜなら、"両方だいじ" なのですから。
 => 両方だいじなんです | jfluteの日記

バランスを見つける旅だし、
両立を見つける旅なのです。

レビューがしやすければ?

逆に、レビューがしやすければ...
o レビュー時間の短縮
  => 早いリリース
   => ビジネス貢献

o レビューでバグ発見
  => 品質の向上、緊急リリース削減
   => ビジネス貢献

o 読みやすいコードの積み重ね
  => 既存コード分析時間の短縮
   => メンテナンスモチベーションのキープ
    => ビジネス意識のキープ
     => ビジネス貢献への積極的な行動

o 変ななコードもレビューで発見
  => 経験浅いディベロッパーのコードもリリースできる
   => リソースマネジメントがしやすくなる
    => ビジネス貢献

o (...などなど)
つまり、先ほどのコードの乱れの
デメリットを抑える効果があり、
そして...

レビューがしやすいコードというのは、
非常にビジネス意識の高いコード

と言えるでしょう。

"プログラミング環境の向上" の一つであり、
非効率メンテの長期化によるエンジニアの離散を防ぎ、
エンジニアのビジネス意識に下支えする重要な基盤となり、
結果的に" ビジネス貢献の向上" につながります。

...

また、まだ経験の浅いディベロッパーであっても、
とにかくレビューしやすいコードさえ心がけていれば、
何かへんてこりんでも優秀な先輩たちが指摘してくれます。
バグを見つけてくれます。それで問題は未然に防げます。
それでビジネスを回していくことができるのです。

また、フィードバックをたくさんもらえることで、
スキルアップのチャンスにもなり、指摘も少なくなってきて、
早いリリースができるようになっていきます。
レビューさえしやすければ、
いきなり正解を引かなくてもいいわけです。

だから、まずはそこ。

レビューしやすいコードとは?

大きくふたつ:

o 統一的なコード
o 理路整然としたコード
統一的なコード
一番簡単に思いつくものはコードの統一性です。
もちろんこれがすべてではありませんが、
大きな要素であることは確実です。

そのための工夫も様々です。
仕組みや運用での工夫が大きな地盤になるでしょう。

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
o 信頼できるアーキテクトにアーキテクチャデザインを依頼
 => アーキテクトのちから | jfluteの日記

o フレームワークをしっかりと使いこなす
 => フレームワークの規約やポリシーに乗っかる

o IDE警告、checkstyleなどによるコーディングスタイルの統一
o ハンズオン研修でのスキル向上と兼ねてポリシーの意識統一
o レビューによる非定型なパターンのコード改善
o (...などなど)
_/_/_/_/_/_/_/_/_/_/

ダメなコード、ダメなポリシーで統一してもダメですから、
"アーキテクチャデザイン" は重要です。
アーキテクトのスキルや気づかい力に依存します。

一方で、ディベロッパー本人の意識やスキルにも依存します。
ここも "両方だいじなんです" ですね。
仕組みと属人の両サイドから攻めていって、
初めてうまくいくものと言っていいと思います。
そう簡単なことではありません。
理路整然としたコード
一方で、なんでもかんでも統一すればいいわけではありません。
ときには問題解決のために部分最適をする必要もありますから。

どうしても統一できないところがあったとしても、
筋道が通っており、かつ、シンプルに表現されていれば、
メンテナンスする上で困らないコードになります。
つまり、"理路整然としているコード" です。
そういうコードが書けるプログラマーは確実に存在します。

ここが世でよく言われる "綺麗なコード" とか、
"わかりやすいコード" という言葉に相当するかもですね。

...

安心してください。
そこまで敷居の高い話ではありません。

o そのロジックに行き着いた背景をコメントする
o 目的と手段を分離したコードを心がける
o などなど

これらをちょっと意識するだけでも、
理路整然に辿り着くための大きな第一歩になります。
お手軽なのでそこから実践してみるとよいでしょう。

...

ちなみに、綺麗なコードという表現は、
誤解を生みやすいのであまり使わないようにしています。
必要不要の1/0の空中戦になりやすいからですね。
とはいえ、やっぱり言葉しては必要で使うは使いますが...
"レビューしやすいコードのための表現方法の一つ"
というニュアンスです。

あくまで、
"どういうコードがビジネスに貢献するのか?"
そこが論点だからです。
お金をもらっているからには。

余談: 差分レビューの罠

レビューはとてもよい習慣で、
レビューによるコードの向上の効果は非常に高いものです。
また、レビューをすることで、
他の人のコードを読むきっかけになりますし、
コードで人とコミュニケーションするきっかけになります。
経験の浅いプログラマーの教育にも非常に効果的です。

最近は、Githubのプルリクを使ってレビューが増えてきました。
差分が非常に見やすく表示され、コメントもしやすくなっています。
ただ、ちょっと差分レビューの罠っぽいレビューをよく見かけます。

差分だけ見て全体をよく見渡すことなく、
プルリクのコメントだけで空中戦をしてしまうこと。

ついつい、Githubのプルリクの画面だけが、
レビューの場になってしまいがちです。
周りのコードがこうなっているからこそ、
そう修正されたのであって、差分のコードだけでは
なんとも言えなかったり、

クラス構造レベルの大きな修正をしたときは、
差分のコードだけではよくわかりません。

「このチケットは face-to-face でやりましょう」
とか、運用として何かアドリブがあって、
レビュー会でレビューイーが説明できるとよいでしょう。

リモートのままだとしても、
レビューイーが概念的な説明を書いて、
レビューワーに全体像を伝えられるとよいでしょう。

...

また、Githubのプルリク画面だけでレビューが終了し、
IDE警告やcheckstyleの見逃し防止がされないのも、
よくあるアンチパターンです。

その基本的なレベルの警告コードがプルリクに上がってくると、
レビューが長くなって仕方ありませんし、
バグ発見や業務的なミス発見のためのレビューの
ノイズになり、本質的なレビューに影響が出ます。
まさしく短期的なデメリットです。
かといって見逃せば、中期的デメリットを積み重ねます。

これはちょっと性悪説ですが、
ディベロッパーの入れ替わりが激しいと、
どうしてもIDE警告やcheckstyleは見過ごされがちです。
気づいたら警告だらけ (真っ黄色) になって、
そうなると新しく発生した警告も気にしなくなります。
事実上の無意味チェックです。

レビューワーの誰か一人でも、
IDE上でコードを開いてチェックする人を設けたいところです。

余談: 自由と法の絡み合い

ツールによる統一的なチェックは運用が難しいものです。

先ほどもありましたが、常に統一というのは難しく、
ケースバイケースが必ず存在するからです。

また、あまりに厳しくなると窮屈にも思えてきて、
別のモチベーションダウンも発生します。
プログラマーとしてある程度は個性も出したい、
と思うのが心情です。
(もちろん、理路整然としていること大前提で)

どこまでチェックするか?
このバランスは常に様子を見て微調整し続けることが大切です。
法律も時代が変われば変わってきます。

...

さて、運用していけばいくほど、
チェックがどんどん厳しくなっていきがちです。
なぜ?

もともとの極論として、

"チェックしなくても統一的で理路整然としたコードが
積み上がっていくならチェックする必要ない"

と言えますが、でも実際はなかなかそうなりません。
でもレビュー会でそのレベルのことまでチェックしていたら、
レビューの時間がながくなってしょうがない。
なので、ツールによる自動化をするわけです。

ズバリ言うと...

ディベロッパーの質が低ければ低いほど、
どんどん厳しくなっていく

のです。
(厳密には、そういうディベロッパーが混じると)

でもツールは、ケースバイケースやバランスを知りません。
融通の利かない画一的なチェックしかできないのです。

もし将来、人工知能checkstyleが登場したら、
「まあ、ここはわかりやすいからOKだぜ、いえーい」
とケースバイケースまで考慮してくれるかもしれませんが、
それ、いまはないです。そこでギャップが生まれます。

これは世の中がそうなっています。
以前は禁止されていなかったものが禁止されたりします。
安易な不注意で事故を起こす人や悪用したりする人がいるから、
禁止になるわけですが...
注意深くしていて事故も起こさず悪用もしない人からすれば、
「えー、べつにいいじゃん」って思うこともあるでしょう。

...

自由や個性を得たければ、
ディベロッパーとして...いや、プログラマーとして、

最低限の統一的を保ちながらも
理路整然で個性も入ってるコードを
書けるようにトレーニングし続ける

のが、ぼくらの宿命でしょう。

レビューワーへの気づかい

レビューしやすいコードを書くためには?

先ほど、統一的なコードのお話のところで、
いくつかの工夫は出しましたが、
極論は、

o 現場現場で考えていかないといけない
o 個人個人で考えていかないといけない

ことでしょう。

考え続けることが答え

と言えるかもしれません。

...

一方で、それをトレーニングすることは幾らでもできます。

o レビューワーにたくさんなればいい
o ソースコードをたくさん読めばいい
o 書いたコードを人に説明すればいい
o リーダブルコード買ってくればいい

よくエンジニアは、
「このときはこうすればOK、このときはああすればOK」
というルールを求めがちですが、
この世の中、そんな簡単な世界じゃない。

お店のスタッフがどういう接客すればお客様が喜ぶか?
お客様視点をまったく持っていないスタッフが、
「このときはこうすればOK、このときはああすればOK」
ってマニュアルが欲しいと言ってきたらどうしますか?

...

レビューワーへの気づかい

そこから思考の始まりです。

f:id:jflute:20100906184928j:image

2016-09-06

ルーズなDaoパターンなら見たくない

|

気にせず突っ込む

Daoパターンというもの自体の説明はしません。
厳密なDaoパターンの話じゃないかもしれません。
ここでは、jfluteが現場でよく見てきた、

ルーズなDaoパターン

のお話。

ただなんとなくDBアクセスを隠蔽しようと、
Daoレイヤにすべての検索を押し込めるDBの検索の実装はとにかくこのクラスで」

そこが再利用領域なのかそうではないのか?
何のためにそこに実装しようとしているのか?

気にせず突っ込む。

最小公倍数パターン

よくある現象のひとつめ。

A画面: 関連テーブル20個持って来て表示
B画面: 関連テーブル3個持って来て表示

でも、AとBの検索は非常に似ている。
違うのは持ってくるデータの量。

A画面が先に実装されました。
B画面を作る人がその実装を見つけました。
public List<Member> selectMemberList() { // author A
    List<Member> memberList = memberBhv.selectList(cb -> {
        cb.setupSelect_MemberSecurity();
        cb.setupSelect_MemberStatus();
        cb.setupSelect_Sea().withDocksideStage();
        cb.setupSelect_Sea().withHangarStage().withMystic();
        cb.setupSelect_Land().withShowBase().withOneMan();
        cb... // many, many setupSelect
        cb.query().set...
        cb.query().addOrderBy...
    });
    memberBhv.load(loader -> {
        loader.loadPurchase(...);
        loader.loadPiary(...);
        loader... // many, many loadReferrer
    });
}
さて、どうするでしょう?

あっ!
B画面が、そのままA画面の検索メソッドを使ってしまいました。
なぜなら...

Daoレイヤの定義されているわけですから、
再利用していいものだと思うでしょう。楽だし。
めでたく微妙に重いB画面のできあがりです。

DBFluteであれば、SetupSelect の数ですね。
Bから見れば大量の不要な SetupSelect が呼ばれている。

...

C画面: 関連テーブル7個持って来て表示

C画面もA画面の検索を再利用しようとしていますが、
ちょっと関連テーブルが足りてないようです。

さて、どうするでしょう?

あっ!
そのメソッドに関連テーブルを追加してしまいました。
なぜなら...

関連テーブルの追加であれば影響はないだろうと
考えるでしょう。楽だし。
めでたく微妙に重いC画面のできあがりですが、
A画面もB画面も微妙に重くなりました。

めでたく最小公倍数のメソッドができました。
public List<Member> selectMemberList() { // author A
    List<Member> memberList = memberBhv.selectList(cb -> {
        cb.setupSelect_MemberSecurity(); // for A
        cb.setupSelect_MemberStatus(); // for A, B
        cb.setupSelect_Sea().withDockside(); // for A, C
        cb.setupSelect_Sea().withHangar().withMystic(); // for A
        cb.setupSelect_Land().withShowBase().withOneMan(); // for A
        cb.setupSelect_Land().withOrleans().withMinio(); // for C
        cb... // many, many setupSelect
        cb.query().set...
        cb.query().addOrderBy...
    });
    memberBhv.load(loader -> {
        loader.loadPurchase(...); // for A
        loader.loadPiary(...); // for A, C
        loader.loadBonvo(...); // for C
        loader... // many, many loadReferrer
    });
}
A画面: 実は要らないテーブルがあった(or要らなくなった)

スピードのためにも、
不要な関連テーブルを削りたい。

さて、どうするでしょう?

いやぁ...
これはもう削れません。
どう影響するのかわからないから、
要らなさそうでも削除する勇気はありません。
(影響を特定するのが時間がかかるし)

この繰り返し、しばらくすると、
実はどの画面も使ってない関連テーブルもできたりします。

でも、削れません。もはや誰がどれを使っているか把握してない。
めでたく最小公倍数 "以上" のメソッドができました。

見事なデグレパターン

A画面が「そのメソッドを修正します!」と言い出しました。
パフォーマンスチューニングでデータ取得の調整や、
絞り込み条件の表現の変更、普通に業務変更による変更など。

A画面からすれば自分で作ったメソッド。
BやCから呼ばれていることに気付いているとは限らない。

再利用されることを意識して作っていれば、
仕事人としては他の画面からの利用を確認したり、
それなりに気をつけるでしょう。

でも、

別に再利用とか気にせず、
"DB検索はDaoに実装しないといけない"
って言うから、そこに書いただけ

という意識で、Daoメソッドを実装しているとしたら、

あっ!

やっちゃった。
見事に、A画面の修正でBとCは動かなくなりました。

A画面「BとCが勝手に再利用してるのが悪いんだ」

なるほど確かに、BとCもメソッド呼び出し時に
もっとちゃんと気をつけるべきでは?

B画面「再利用してよさそうなメソッド名してたし」

A画面さん、再利用される想定ではなく作ってるのであれば、
Daoメソッド名に "selectForA画面()" とか、
露骨な名前を付ければよかったのでは?

でも、なかなかそんな負けた感たっぷりのメソッド名、
かっこ悪くて付けづらいです。
そこはなんだかDaoレイヤであることを少し意識して、
画面には依存していない "それっぽい名前" を付けるでしょう。
なんとなく...

こうやって、再利用が曖昧なメソッドが、
Daoメソッドに大量にできあがっていきます。

再利用すべきでないものが、
再利用してもよさそうなレイヤに実装されている罠

特に事業会社でのインクリメンタル開発では、
これがボディブローのように効きます。
人もどんどん入れ替わりますから、
経験者でも罠に引っかかりやすいです。

そうなると、もうDaoメソッドに対する信頼がありません。
「このDaoメソッド、ほんとに呼んで大丈夫なのか...」
本当に再利用できるDaoメソッドまでくすんでしまいます。

ルーズな再利用が、
しっかりした再利用を引きずり落とす

ちなみにこれは、単に検索の話に限りません。
「ビジネスロジックでもまったく同じ」です。

引数リモコンパターン

「さすがにそんな最小公倍数はやらないよ!」
「デグレも考えてなんとか工夫する!」
とします。

そこでできあがるのが、"引数リモコンパターン" です。
これは、こちらの記事をお読みください。
(また読んだら戻って来てくださいね^^)

// メンテ不能の強者、引数リモコンパターン
http://d.hatena.ne.jp/jflute/20160905/argremocon
public void index() {
    // what do you select?
    ... = logic.selectNandemoMember(null, "S", null
            , false, true, false, CDef.MemberStatus.Formalized
            , true, false, true, true);
}
B画面やC画面が、
自分たちに必要な分だけの検索を引数でどうにか...
A画面も修正時は引数でどうにか...
そして...

再利用しまくって、メンテするの怖いから、
パフォーマンスチューニングもできない

もう一度言いますが、これ最悪です。
事業会社では致命的なビジネスインパクトがあります。

入り組んだ分岐で検索の全体像が見えないので、
チューニングによる条件表現の変更もしづらい。
見事なデグレが怖いから。

ルーズなDaoパターンはまだまだ続きます。

引数めっちゃ画面依存パターン

検索条件をどうやってDaoに渡すのでしょうか?
例えば、Formクラスにリクエストパタメーターが
詰まっているとします。

Daoレイヤは、通常Webには依存しません。
というか、通常画面仕様にも依存しません。

Formの値を、Daoレイヤが受け入れるための
Beanクラスとかに詰め替えてメソッドを呼びます。

A画面のFormを引数にしていたら、B画面が呼べません。
A画面のFormを使ったらそれこそA画面に依存してしまいます。
なので、再利用するためには必要なことです。

でも確かに面倒ですね。
なので...

めでたく、
A画面のFormを引数の形にしたDaoメソッドのできあがり。
// Dao method
public List<Member> selectMemberList(AForm form) { // Form?
    ...
}
なんか、先ほどの最小公倍数や見事なデグレを考えると、
その方がへたな再利用されないからいいのかな!?
って皮肉な考えも理解できなくもないです。

ただ...
「そのDaoクラスは何のためのDaoなのか?」
単にパッケージとクラス名が違うだけで、
事実上A画面のものじゃん!

でも、そういう体裁になってない。
紛らわしいことこの上ない。

もちろん良いことは?

もちろん、Daoパターン自体には良いことがあります。

DBアクセスを隠蔽することで、
DBが変わった時でも画面側に影響なく変更ができます。

ほんとに?

ちゃんとしたDaoパターンのデザインができていれば、
できるでしょう。

ですが、それ自体がなかなかハードルが高い
特にRDBの検索はパフォーマンス論理などが絡むため、
クラス参照的には画面から切り離されていたとしても、
潜在的に依存しているということがよくあるからです。

少なくとも "ルーズなDaoパターン" では、
その潜在性を排除できないでしょう。
(というか、排除できてないからルーズなDaoパターン)

また、DBを何かに差し替えるような変更、
そんなしょっちゅうはありません。
Daoパターンでなくても変更できないわけじゃないので、
その辺の費用対効果をどう考えるか?

...

もう一つ、
一つのレイヤDB検索がすべて集っているので、
横断的に見て管理しやすい、というポイントがあります。

もし、このメリットを重宝したいなら、
A画面のFormクラスを引数にしたDaoメソッドだとしても、
まあ100歩譲れば譲れなくはないかなと思います。

でも、そのメリットを本当に享受してますか?
Daoを横断して管理するような役割の人が、
プロジェクトに本当にいますか?
結局ただ置いてるだけだったら、もったいない。

...

さらにもう一つ、
縦割りのリソース配分がしやすくなります。

でも、縦割りマネジメントには別の問題も発生するでしょう。
代表的なのは、互いが互いのレイヤに対して無関心になること。
とある画面、そこで動くプログラムの全体を誰も把握していない。
そこから様々なすれ違いが発生します。

少なくともjfluteは、Daoというレイヤを基準に、
ディベロッパーの縦割り配置はしないでしょう。

ちゃんとDaoパターンするには?

jfluteの経験上、

「何の思想と工夫もなくただDaoパターンを採用」すると、
ほぼ間違いなく今までのアンチパターンが発生していました。

ちゃんとやるなら...

Daoを横断して管理する専門レビューワー

という役割の人が必要だと考えます。
おかしなことになってないか常にチェック。
ディベロッパーメソッドデザインに悩んでいたら、
相談に乗ってあげる。率先して悩みを見つけてあげる。
ときに、その人がリファクタリングもします。

これはDao限らず再利用レイヤでも同じことが言えます。
だがしかし、大抵こういう人はいません。

なかなかそういう役割を重宝してマネジメントされることは
なかなかないでしょう。

仮にそういう役割が明確にできたとしても、
その任務をしっかり遂行できる人がいるでしょうか?
技術力も必要だし、整理整頓能力も必要だし、
コミュニケーション能力も必要だし、業務知識も必要だし、

業務ドメインをしっかり意識できるか?

仮にできる人がいて、
その任務をその人がずっと続けてくれるでしょうか?
地味でつまらない仕事です。

やはり DBFlute では Dao はオススメしない

DBFluteには、LazyLoad がありません。
Entityのgetメソッドを呼びだしたら、
その場でSQLを発行してデータを持ってくる機能です。

高機能なO/Rマッパーには備わってることが多いですが、
DBFluteはあえてこの機能をサポートしていません。
RDBのデータは明示的に取得を宣言する方が良いと
考えているからです。

別のマシンのハードディスクからデータを持って来ている
という意識、これを失いたくないからです。
コードを見れば何を転送しているのかわかるように。

LazyLoadが備わっていれば、
Daoパターンは比較的やりやすいように思います。
少なくとも、先ほどのアンチパターンの幾つかは、
自然と防ぐことができるからです。
その代わり別の問題も発生するかもしれません。
そこはトレードオフです。

...

ということから、
"Daoパターンでないと解決しない問題"
というのが現場で出てこない限りは、
DBFluteとしてはなかなかオススメはできません。
やるならやるでルーズにならないように。

すでにある程度のDaoがある!?

一方で、DBFlute の Behavior は、
すでにDaoレイヤと言えるかもしれません。
DB検索の面倒な手続きを隠蔽しています。
ただ、DB検索の指示は自分ではしません。

A画面が必要なデータはA画面が決める

そういえば、A画面って言ってますが、
A業務とかAロジックと言い代えられます。

Aロジックが必要なデータはAロジックが決める

ConditionBeanがそれに近いかもですね。
検索要件だけを ConditionBean で表現して、
手続きはBehaviorにお願いする。

「DBの手続きを隠蔽する」という意味合いでは、
すでにある程度の再利用は済んでいるとも言えます。

where句の部品再利用

引数リモコンパターンのところでだいぶ語りましたが、
DBFluteでは、検索ロジックは部品単位で再利用する、
のがオススメであると。

Exクラスに定義する ArrangeQuery です。
 => where句の再利用 | DBFlute
memberBhv.selectList(cb -> {
    cb.setupSelect_...

    cb.query().arrangeServiceMember(); // *here
    cb.query().set...

    cb.query().addOrderBy_...
}
少なくとも事業会社でのインクリメンタル開発では、
再利用は慎重に。ルーズにならないことが大切でしょう。

再利用だけがメンテナンスしやすさの指標じゃない。
一方で、再利用はぼくらには欠かせないもの。

でも、ぴったり必要な分だけ再利用する、
というのはほぼ不可能です。
その "ぴったり" を探そうと努力はしますが、
どうしても「再利用し過ぎ or 再利用し足りてない」
のどちらかに寄ってしまいます。

再利用し過ぎてるくらいであれば、
再利用し足りてない方がまだマシ。

再利用し過ぎると、
本当に再利用したいものが見えなくなる。
信頼できる再利用メソッドを守りたい。

そんなバランス感覚です。

ファイル分割と再利用は別問題

ときどき、

「Daoパターンじゃないと、ActionやServiceが肥大化する!」

と聞くことがありますが、
ファイル分割と再利用は別問題です。

ですし、

「肥大化してるからDaoに持っていく」

という理由で持って来たDaoメソッドこそ、
ルーズなDaoメソッドと言えるでしょう。
どうせ作るなら、そんな理由じゃなく作って欲しい。

画面側、業務側のクラスをどういう粒度、
どういうポリシーで切り分けていくか?
もともと存在する、また別の課題ですね。

LastaFluteでは、
Assistクラスという概念を導入して、
再利用するものと再利用しないものを明確に分けつつ、
気軽にファイル分割もしていくポリシーを提案しています。
 => Actionの実装デザイン | LastaFlute

何をどこに実装するか?

DB検索は Dao に書くべき。
Controller にベタベタ書かず Service に書くべき。
なんとかはなんとかに書くべき。

さまざまな「べき」をよく聞きます。

別に間違ってるわけじゃないですが、
なんでそこに書くのか?

そこをちゃんと理解せずに実装していたら、
その本来のメリットをしっかり享受する
メソッドデザインができないでしょう。

そこをちゃんと理解せずに実装していたら、
そのとき発生するデメリットを回避する
メソッドデザインができないでしょう。

"ここ" に書くとメリットがこうでデメリットがこう。
"そこ" に書くとメリットがこうでデメリットがこう。

しかもそれは、使っているフレームワーク、
そのプロジェクトメンバーの状況、
そのサービスの特性、今後の展望、
それらによって微妙に変わってきます。

安易に型にはめただけの浅い判断で、
あっちだこっちだと言っていても、
どのレイヤでもルーズになってしまうでしょう。