bon now

ありのままの現実を書き殴る吐き溜め。底辺SEの備忘録。
Written by bon who just a foolish IT Engineer.

JSFとJBossとJavaScript

Created Date: 2013/08/08 22:44
Updated Date: 2023/11/05 03:00

なんだかんだでJBoss暦が2年を経過しそうな今、いろんな意味でJBossのすごさを感じている。
例えば以前投稿(JBoss seamでtestNGのSeamTest続 JBoss seamでtestNGのSeamTest)したように、TestNGとSeamTestなるモックによるテスト自動化とか、JBoss chache、JBossWSやJBossBPMとか。
まあ、JBoss cacheとBPMは正直使ったこと無いので「便利そうだな」というくらいの感想しかないけど。
今日はそのJBossに対するお話で、日頃からJBossって便利だけど、便利すぎて何かしらコーディング制約しないと何してるか分からないコードが出来上がるねという内容である。
(なお、この記事では便宜上 JBoss = JBoss Seamを表している)

普段JBossを利用している人が使うと思われるフレームワークは、主にHibernateとJSFだろう。 JSFはEL式というHTMLへ特殊な埋め込み記法を用いることで、JBoss Seamのコンポーネントを簡単にぶち込むことが出来る。
Railsを使っている人の場合はERBをイメージしてもらうといい。 そしてHibernateは、JSFから参照されるモデルの値に対し、DBからデータを取得して設定する役目を担っている。
このHibernateはO/Rマッピングツールなわけで、例えばSessionModelというモデルを定義し、 その中にString id,String nameなど特定のテーブルカラムと同様の項目を定義すれば、 それをそのままJavaのモデルとして利用することが出来る。
まあ、そもそもEJB3で完結するようなことを、 JBossは上手くそれを色々なフレームワークおよびツールで補いながら、 開発者が作りやすい環境を与えてくれているというわけだ。 事実、EJB3だけでは手続き的に面度なことやあんなことやこんなことを、JSF、Hibernateが補っているのだ。 そうに違いない(実は理解度はまだ低い)

で、ここからが本題だ。

そんな便利なJBossだからこそ、思うがまま、許されるがままコーディングをしまくっても、 案外ちゃんと動いてくれる。
でも、そんなことだと必ずといっていいほどコーディング規約が統一されておらず、 個々人によって好き勝手に荒らされたソースコードのスパゲッティだけが残ることになる。
こうなると後の祭りで、どこに手をつけたら何が変わるかとかこの処理何?という状況になり、 PGerはソースコードを読みながら、結局頭の中でもう一度コーディングをするハメになる。
こういう単純で面倒な振り返り作業が、結果的に工数の増加や、
問題の潜在化を生み出し、生産性・品質の低下を招くことになる。

特に僕が問題だと思っている部分は、設計書には存在しない箇所に処理が存在していたり、
遠く離れた場所(別ファイルやHTMLの下のほう)で実行されるJavaScriptだったり、
onload、onclick、onchangeなどに直に書かれたJavaScriptだったり、 無駄な作業をやりまくるfactoryアノテーションだったり、 JSFで初期表示時やら画面遷移時やらでやたらサーバ処理をさせまくる処理だったり、 そんな部分だ。

特に最初に述べた処理の場所が分からない(設計書と相違がある)というのは大きく、
例えば日付のデータ変換を、クライアントサイドでValidateしたいからといってJavaScriptでやるとか。
それをやるならまず設計書に書いておきなさいという話。 Validateの処理の1つだから大丈夫とか思ってる人もいるだろうが、
勝手に文字列の型を変えられると、サーバサイドでいざDBへクエリを実行しようとしたとき、
可笑しなデータがプレースホルダに飛び込んで来たもんだから、SQLエラーが発生することになる。
そして、これで済めばまだいい。
Javaの場合、そのほかの部分でExceptionが出て、根本原因にたどり着くまでに時間がかかるなんてことは、 こういうプログラムを書いている場合だとよくある話。
苦労するのは自分なのだから、その辺はしっかりして欲しいとは思う。
また、この話は処理が遠く離れたところで実行されるというのにも絡んできて、
結局書いてない&どこにあるか分からないのオンパレードのプログラムは、 誰の目から見ても(コンピュータ以外!)分かりにくくムカっとくるもんだ。

ということで、便利なツールを使う上でも、それぞれの処理をどこで、 どの端末が、どのようにやるかくらい設計し、ドキュメント化しておくことが親切心だと思う。

そういうコーディング規約を前もって作っておくことも一つの手だろう。
とにかく、出来ることが多いと、色んな場所で色んなことをやろうとするもんだから、 ソースが汚くなりがちになる。
これは意識しておかなければならないPGerのマナーだ、と思う。。。

local_offer
JSF
folder work