No Programming, No Life

新しいNPNLです。http://d.hatena.ne.jp/fumokmm/ から引っ越してきました。

コードを自動生成するか否か

メッセージIDのenumなどを作る際に、定義書から自動生成する場合がある。

こういったボイラープレートは自動生成で逃げるのが良いかもしれないのだが、その自動生成ツールなり、スクリプトなりが後からきちんと運用されなくなったりする場合を考えると、なかなか難しいところである。

また、例えば、定義一覧のような設計書から定義内容を自動生成するような場合、たとえば区分が一つ増えたときに、どういったプログラムコードに変換するのかといったようは、単純に設計書の修正だけでなく、最終的に生成されるプログラムコードのことも考えて、拡張してゆかなければならなくなる。
こういったことが、前述のように、運用されなくなる要因の一つでもあるように思う。

やはり、プログラムコードというのは職人の仕上げる飴細工のように繊細なものなのだと思う。

引き継ぎ者不在のシステム

私が前に携わっていたシステムで、専任して保守してい方が、会社を退職されるらしい。

体力のある会社であれが後任をすぐに立てられるんだろうけど、そこそこの規模の会社さんだとそうも行かないらしい。
私にも、元開発者だったということで、またお仕事の話がくるかも知れない。

偏りはあるかもしれないが、システム開発会社のような会社の週報が、紙ベースであったりと、色々と世の中まだまだだなぁと思うところはありますが、この引き継ぎ者不在のシステムの未来はどうなるんだろうか。

No Project Small Library Principle

ある日、業務コードを眺めてていたら、ふとXMLをダウンロードさせるWEBプログラムのソースに出くわした。
それだけだったら何も目新しいことはないだろう、十分に使い古されたフォーマットであるし、何も目にとまることなど無いはずであった。しかし、何かがおかしい。

そのコードは、JDK標準クラスのみで書かれていたのだ。このライブラリやらフレームワークやらが溢れた時代に、まさか素のJDKだけ書かれた大規模なプログラムに出会うのは、私としてはとても珍しいことであった。
DOMを駆使して、最後はインデント処理まで施して出力しているのである。ライブラリが無かった時代ならそうであろうが、よりによって今どきそれ?と最初は思ったのであった。
しかも今回のプロジェクトではJava8を使っているし、古い環境だったというわけではない。開発者も昔からの古参Javaプログラマというわけではなく、それなりに若い世代である。
さて、彼らはどうしてこんなコードを書いたのか。

そのあと私は、だいぶ迷った挙句、そのソースの多様性を認めることにした。それはまさに、以下の原則に辿り着いたからである。

プロジェクト向けの小さなライブラリを書いてはいけない。
いつの日か、そのライブラリは運用チームでは
手に負えなくなり、メンテナンスされなくなる。
最後には放棄されるだろう。

どういうことか。
ここで言っているライブラリとは、世に出回っている汎用的なもの*1ではなく、各プロジェクト向けに存在する、そのプロジェクト向けの小さなライブラリのことである。

自作したそのプロジェクト独自のライブラリを極力使わないことで、より一般的な記述のみへと落とし込むことができる。プログラマの中には、こういった小さなプロジェクトライブラリを作ることを生業としている種の人物もいるであろうが、残念ながら長い目で見るとプロジェクトのためになっているとは言えない。
そのプロジェクト固有のビジネスロジックを含んだライブラリは、いつか管理しきれなくなるものだ。いつまでも書いた人物がプロジェクトに残ることは稀である。ビジネスロジックはライブラリに埋め込むのではなく、機能ごとの処理層に埋め込むべきである。

小さなライブラリを書く代わりに、我々に必要なのはマニュアルであり、チュートリアルであり、QAだ。Javaの基礎知識を持ったメンバーが新たにプロジェクトに参画した際、素早くコードを追加し、メンテナンスし、テストできるようにさせるには、これらのドキュメントが必要だ。

この原則に従う限りに於いては、長期的にメンテナンスしやすいコードを書くことが期待できるのではないだろうか。

最後に、一応書いておくが、全てのライブラリを書いたり、利用したりするなと言っているわけでは無い。十分に知られた*2ライブラリであれば、緻密に汎用化されているし、またドキュメントも充実しているだろう。その最たる例はJDKではないだろうか。

*1:Javaならjarにて提供されるもの

*2:この業界では、よく「枯れた」と表現する

技術は繋がっている

どうも、ふもです。

最近は新しいプロジェクトのアプリケーションアーキテクトなどという大層な役割を与えてもらい、日々奮闘している毎日です。

長らく新しめな技術から遠ざかっていたため、Java8やらSpring4などの環境がやっと使えるようになりました。
日々、調べながら、フレームワークとして採用する部品を作り続けている毎日ですが、そんな中で一つ思ったことがあります。それがタイトルでも書いた、技術は繋がっているんだなぁということです。

たとえばSpringとかなどですと、最近はアノテーションを多用するスタイルになっていたり、JavaConfigで定義がかけたりと、だいぶ進化しているようです。
しかし、いきなりこの姿になったわけでは勿論ないわけで、色々な機能を調べてると、私の空白の数年間の間に、様々なことがあったのだなぁと追体験ができてたのしくなります。

様々な技術が出ては消えて行くなかで、それを常に楽しめる姿勢で、今後も技術者を続けていこうと思いました。

コードはそのプロジェクトメンバー達のスキル上限までにしかならない

コードの完結さやスマートさは、結局はプロジェクトメンバーに左右されるという意味。
より洗練されたコードを目指すのであれば、プロジェクトに携わるメンバーへの教育や布教活動が欠かせない。
コードのスマートさは、将来に渡って長い間コードを維持し続ける際に必須の条権となってくるため、妥協してはならない項目の一つである。

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
    )

列名が揃ってないと使えないですが、だいぶコードの見通しが良くなりますよね。デーブル設計時からこれを見越して、結合する予定の列名は統一しておくと良さそうな気がしました。


さて、いかがだったでしょうか。
私自身は、普段何気無く使っているものの中にもまだまだ未知のものが隠されていることを実感できてなんだか面白かったです。
もうこんなことは知っていると門を閉ざさずに、一度、よく見知った言語や製品などのマニュアルやリファレンスを眺めてみることをお勧めします。

WIkipediaに寄付してみました

どうも、お久しぶりです。
暑くなってきましたがみなさんどうお過ごしてしょうか。

最近Wikipediaさんにアクセスすると
寄付して欲しそうな切実な広告がでるようになっていた。
f:id:fumokmm:20140721012504p:plain
f:id:fumokmm:20140721012534p:plain
やっぱりWebサービスの運営にはお金がかかるんですねぇ、同じIT業界に関わらせてもらっている身だし、Wikipediaさんには多かれ少なかれお世話になっているし、今後もきっとお世話になるだろうなぁという思いがあったので、多くはないですが寄付させていただきました。

f:id:fumokmm:20140721012547p:plain
微力ながら、ITの発展へと寄与できたら幸いです。