No Project Small Library Principle
ある日、業務コードを眺めてていたら、ふとXMLをダウンロードさせるWEBプログラムのソースに出くわした。
それだけだったら何も目新しいことはないだろう、十分に使い古されたフォーマットであるし、何も目にとまることなど無いはずであった。しかし、何かがおかしい。
そのコードは、JDK標準クラスのみで書かれていたのだ。このライブラリやらフレームワークやらが溢れた時代に、まさか素のJDKだけ書かれた大規模なプログラムに出会うのは、私としてはとても珍しいことであった。
DOMを駆使して、最後はインデント処理まで施して出力しているのである。ライブラリが無かった時代ならそうであろうが、よりによって今どきそれ？と最初は思ったのであった。
しかも今回のプロジェクトではJava8を使っているし、古い環境だったというわけではない。開発者も昔からの古参Javaプログラマというわけではなく、それなりに若い世代である。
さて、彼らはどうしてこんなコードを書いたのか。
そのあと私は、だいぶ迷った挙句、そのソースの多様性を認めることにした。それはまさに、以下の原則に辿り着いたからである。
プロジェクト向けの小さなライブラリを書いてはいけない。 いつの日か、そのライブラリは運用チームでは 手に負えなくなり、メンテナンスされなくなる。 最後には放棄されるだろう。
どういうことか。
ここで言っているライブラリとは、世に出回っている汎用的なもの*1ではなく、各プロジェクト向けに存在する、そのプロジェクト向けの小さなライブラリのことである。
自作したそのプロジェクト独自のライブラリを極力使わないことで、より一般的な記述のみへと落とし込むことができる。プログラマの中には、こういった小さなプロジェクトライブラリを作ることを生業としている種の人物もいるであろうが、残念ながら長い目で見るとプロジェクトのためになっているとは言えない。
そのプロジェクト固有のビジネスロジックを含んだライブラリは、いつか管理しきれなくなるものだ。いつまでも書いた人物がプロジェクトに残ることは稀である。ビジネスロジックはライブラリに埋め込むのではなく、機能ごとの処理層に埋め込むべきである。
小さなライブラリを書く代わりに、我々に必要なのはマニュアルであり、チュートリアルであり、QAだ。Javaの基礎知識を持ったメンバーが新たにプロジェクトに参画した際、素早くコードを追加し、メンテナンスし、テストできるようにさせるには、これらのドキュメントが必要だ。
この原則に従う限りに於いては、長期的にメンテナンスしやすいコードを書くことが期待できるのではないだろうか。
最後に、一応書いておくが、全てのライブラリを書いたり、利用したりするなと言っているわけでは無い。十分に知られた*2ライブラリであれば、緻密に汎用化されているし、またドキュメントも充実しているだろう。その最たる例はJDKではないだろうか。
技術は繋がっている
どうも、ふもです。
最近は新しいプロジェクトのアプリケーションアーキテクトなどという大層な役割を与えてもらい、日々奮闘している毎日です。
長らく新しめな技術から遠ざかっていたため、Java8やらSpring4などの環境がやっと使えるようになりました。
日々、調べながら、フレームワークとして採用する部品を作り続けている毎日ですが、そんな中で一つ思ったことがあります。それがタイトルでも書いた、技術は繋がっているんだなぁということです。
たとえばSpringとかなどですと、最近はアノテーションを多用するスタイルになっていたり、JavaConfigで定義がかけたりと、だいぶ進化しているようです。
しかし、いきなりこの姿になったわけでは勿論ないわけで、色々な機能を調べてると、私の空白の数年間の間に、様々なことがあったのだなぁと追体験ができてたのしくなります。
様々な技術が出ては消えて行くなかで、それを常に楽しめる姿勢で、今後も技術者を続けていこうと思いました。
コードはそのプロジェクトメンバー達のスキル上限までにしかならない
コードの完結さやスマートさは、結局はプロジェクトメンバーに左右されるという意味。
より洗練されたコードを目指すのであれば、プロジェクトに携わるメンバーへの教育や布教活動が欠かせない。
コードのスマートさは、将来に渡って長い間コードを維持し続ける際に必須の条権となってくるため、妥協してはならない項目の一つである。
Appletを改修するお仕事とシステムリプレースについてふと思ったこと
どうも、ふもです。
だいぶ長いこと携わってきたシステム維持のお仕事が一区切りついたので、この5月から新しく開発の仕事に関わることになったのですが、新しい仕事内容を聞いてみてガックリ。それは、Appletを改修する仕事だったのです。
Appletと言えば、Javaが出だした頃に目玉として押し出されてきた機能ですよね、ブラウザ上のUIをHTMLよりもリッチにして、ウェブの可能性を求めて作られたのだと思います。企業での導入が盛んに行われたのがたぶん2000年初頭くらいで…その第一次改修があったのがきっと2004年〜2005年くらい。そしてそれからWEB2.0など様々な変革がWEBの世界には起こり、そして更に10年が経過した今、時代に取り残されたかのように、大量のApplet製の業務アプリケーションが世の中に残ることとなったわけです。
企業としても、この膨大な資産をすべて捨てて一から作り直すほどの余裕もなく、当然継ぎ接ぎだらけの改修を続けていくことになります。今回私が関わらせて貰っているのも、こういった経緯かと思われます。歴史は繰り返すという言葉がありますが、VB6アプリをVB.NETアプリにリプレースしましょう！といったノリととてもよく似ているように思います。システムやアプリケーションは自ら変化することができないスタティックな存在です。ですから、一度世に生み出された、長年使い続けなくてはならない大量の業務アプリケーション資産は、後の世代のエンジニアによってリプレースを余儀なくされるというわけですね。中には、もういらなくなった機能など、破棄されてしまう部分もあるでしょうが、業種にも寄るとは思いますが、少なからず、余程大きな業務改革がない限り、業務の内容はさほど変化があるわけではなく、移りゆく世の中の流れ・人々の流行・それからデータそのものなどに併せて、アプリケーションは姿かたちを作り替えられなくてはならないものなのでしょう。
私達エンジニアに出来るせめてものことは、後の世代のエンジニアが頭を悩ませなくても住むように、努めて綺麗なコードを書いたり、シンプルなフレームワーク・データ構造を維持したりして、可読性と機能性のバランスを保ったシステムを構築しておいてあげることだと思います。
いつか、システムがスタティックな存在ではなく、ダイナミックな存在（AI的な？）になるその日まで、我々エンジニアの仕事がなくなることはないでしょう。
SQLのANY, SOME, ALL, USINGについて
どうも、ふもです。
なんだか今年の夏は雨ばっかりですね。
さて、今日はSQLについてです。
現在携わっているお仕事ではOracleデータベースを使っているのですが、とある事情でSQLのリファレンスを眺めていたら、ほとんど使わないキーワードに出会いました。
タイトルにあるように、ANY, SOME, ALLとUSINGについてです。
ちなみにいままで、業務で取り扱ってきた様々なシステムで見かけたことは無かったと記憶しているので、そうとう珍しいんじゃないかなと思います。
機能の詳細はググってもらうとして、ANYとUSINGだけ軽くどんな感じなのか紹介して終わりにしたいと思います。
ANY
ANYはINとほぼ同じ感じで利用できるようです。
SELECT * FROM デーブル WHERE AAA = ANY(10, 20, 30)
個人的に強力だなぁと思ったのは、複数の値の組み合わせでマッチできるところです。
SELECT * FROM デーブル WHERE (AAA, BBB) = ANY( (10, 'a'), (20, 'b') )
ちなみに、SOMEはANYと同じ意味で使えるらしいです。エイリアスですね。
ANYで複数の条件を指定した場合は、そのどれかにマッチした行が残ります。
あと、ALLは逆に全てにマッチした場合のみ行が残るみたいです。
USING
よく使われるキーワードですが、ここではINNER JOINとかLEFT JOINとかのテーブル結合の時に使うもののお話です。
USINGはONの代わりに結合条件を書く時に利用できます。結合するテーブル同士の列名が同じ場合で、等結合となるような場合に利用できます。
FROM T1 INNER JOIN T2 USING (AAA, BBB, CCC)
これは、ONを使った場合の以下と同等の意味になります。
FROM T1 INNER JOIN T2 ON ( T1.AAA = T2.AAA AND T1.BBB = T2.BBB AND T1.CCC = T2.CCC )
列名が揃ってないと使えないですが、だいぶコードの見通しが良くなりますよね。デーブル設計時からこれを見越して、結合する予定の列名は統一しておくと良さそうな気がしました。
さて、いかがだったでしょうか。
私自身は、普段何気無く使っているものの中にもまだまだ未知のものが隠されていることを実感できてなんだか面白かったです。
もうこんなことは知っていると門を閉ざさずに、一度、よく見知った言語や製品などのマニュアルやリファレンスを眺めてみることをお勧めします。
