grush-blog

様々なフレームワークを組み合わせて

様々なレイヤを設けて

様々なルールをつくって・・・

品質を一定に保つ事は大事なんだけど、よく見かけるのが「やりすぎフレームワーク」

レイヤ間の疎結合にこだわりずぎるあまりに発生する「無理なつじつま合わせ」の連続。

疎結合にする事よって得られる恩恵以上の負担を発生させてしまっては本末転倒。

それに気づいた方が良い。

美しいと思っているのは、共通チームの人間だけ。

生産性はガタ落ち。

上がると幻想されているメンテナンス性も、実は至って低い。

Dto(Vo)のコピー処理ばっかりなソースも何の意味も持たない。

破錠を防ぐためのコードがいっぱいで、本来の処理が見えなくなってしまっては

何のためのJavaであるのか、何のためのフレームワークであるのか・・・

無駄なソースが増える事によって、eclipseの動作もsvn同期もtomcat起動も遅くなっていく。

これって実は重要な事で、プロジェクト規模が大きくなる程、これらの合計時間って決してあなどれなくなってくる。

ビルドとか起動の待ち時間って、コーディング担当者のモチベーションにも影響与えるしね。

個人的には、破錠を防ぐための処置が発生した地点で、その共通方針は間違っていると思う。

あと、仮にしょうがないケースがあるのであれば、いっそ破錠させてしまった方が良い。

そっちの方が絶対にソースがすっきりして読みやすくなる。メンテナンス性も向上する。

簡単に済む事は簡単に済ませる事が大事だと思う。

ついでに、難しい事が簡単に済むような考えも大事。

ところが、いまだにJavaの世界には「難しい事をするのがカッコイイ」って信じている人って多いんだよね。

そんな人に出会うたびに「またか」って思ってしまう・・

いや、共通チームだけが難しい事をするのはとても大事な事だと思うよ。

各担当者が「楽にだけ」なる事を積極的に行うのはとても大事。

各担当者に「これをこう使うと楽になるんだよ」って変なアーキテクチャ押し付けたり、

すぐにエラーを出すような、やたら頑固なツール作ったりするのは、かなり問題。

共通部品を、作った側と使う側の温度差を意識する事ってかなり重要だと思う。

自分が共通基盤に関わる時は、そんな事を常々考えながら進めている。

いつも試行錯誤ではあるんだけれど・・・