型とO/Rに振り回された件

タイトルの通り。

今年の振り返りをしようと思ったけど、まだ一週間近くあるのでその前に・・ 今やってる案件でこんなことに困ったよって話でも書いておこうと思った次第。 というか、近頃忙しくて全くブログを書く時間がなかったので、反省をこめて。

メインのスキルがPHPやJSなどのスクリプトWEB寄りの自分ですが、最近はJAVAJAVAしています。 まぁ、触ったことのない言語のプロジェクトに突っ込まれるなんてよくある話なんですが・・ たまったもんじゃないスキルがあがっていいよね！！

というわけで、今はSpringMVCをメインに書いているわけなんですが・・まー分かんない。。 処理の流れは読める。やりたいことも、やってることも読める（100％理解しているかは別問題）。 ビジネスロジックは「書ける」んだけど、それが「Better」であるかは別問題なわけです。 それで、今の自分がBetterなコードを書けているかと日々悶々としている状況です。

しかも、PHPerだった自分がいきなりJAVAをいじくってると、「型」というものをこれほどまでに意識しないといけないかって改めて思い知らされた。 でもまぁ、やってみると・・確かに型は正義だと言われるのもよくわかる。 想定される値が想定通りに入っていることは安心感もあるし。。 この「想定される」ってのが重要で、チームで開発をすると個人間での感性によって受け取り方が変わってしまうこともない。 「こういう値をいれよう」ではなく、「こういう値しか入らない」としてしまえば、つまずいたときに「何故」を考えて自問する時間もできる。 勢いだけでコードを書く（自分みたいな）エンジニアにはいい薬になる。

ただ、O/Rマッパー・・・お前はダメだ！！ いや、だめというか・・・僕には合わない・・ BDをオブジェクトとして扱えるし、型もDBに合わせるので、操作性もいい。 命名規則さえしっかり守ってれば、あたかもテーブルをオブジェクトのように使うことができる。 そう、設計のしっかりしたCRUDを扱うDBならね。

実際の業務でしっかり設計が決まってることなんて稀だし、単純なI/Oだけのテーブルなんてない。 （あ、設計DISじゃないですよ） プロジェクトが進めば進むほどに「やっぱりあれも」「これはこうしたい」という話がでるなんてザラ。 それに柔軟に対応しようとすると、O/Rマッピングしているが故に別のオブジェクトで対応しないといけないケースもある。 んで、集計なんてしようならオーバーフローが起こったりなんてこともある。。

まぁ、ただ自分が知らないだけで、もっとうまいやり方があるのかもしれない。 というか、普通に考えたらあると思おう。 自分が書いてて気持ち悪いと思ってる部分には、必ずBetterなコードが存在すると思う。 ただ、今はリファクタをする時間がないので突き進むしかない。。

結局、「かもしれない」を存分に意識して、シンプルなコーディングを心がけていくしかないのかなー。 完全に対処療法なんだけど、業務システムを作る上では仕様が唯一の正解なんだろうし。。 自分たちが考えたプロダクトなら、もっと別の道もあるんだけど。。。

うーん、あまりタイトル関係ない話になってしまった。 早くPython実戦投入したい。