読者です 読者をやめる 読者になる 読者になる

エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

久々にStrutsの開発をして思ったこと

f:id:suzaku0914:20160330215903p:plain

経歴

4年位前は、Seasar2を使った現場にいて、3年間働きました。
その後、1年前にStrutsの現場に入って開発を1年間続けた。
Strutsはもっと昔に何度もやったことがあって、FW的な動きは知っているけど、いざやってみると上手くいかないのよねぇ~

環境

Java1.6
Struts1.2
eclipse

その他の環境は飛ばします。
本番環境はLinuxです。

問題だと思ったこと

  1. 1リクエスト1アクション
  2. Struts-config.xmlが面倒

1リクエスト1アクション

Strutsは、1リクエストに対して1アクションクラスを作りますが、コレが害悪だと思いました。
1リクエスト1アクションということは、1機能作るのに複数のアクションクラスが必要になります。
そのため、機能を作る毎にどんどんアクションクラスが増えていき、カオスな環境が出来上がります。
自分のいた現場はそうでした。多分1000クラスはあると思います。
これが原因で、機能を探したり、クラスの移動が面倒でした。
ただ、おかげでeclipseのリソース検索のショートカットの使い方は覚えましたが、こんな経緯で覚えることになるとは思いませんでした。。。
また、クラスが多いことでeclipseの起動にえらく時間がかかる。
たまに反応しないことがあって辛かった。。。。
反応しないのが、障害対応時に発生するとテンパッてしまう結末。心臓にもあまりよろしくない。

少し話が逸れました。あまりにも辛くてここで吐露するしかないのです。
機能を実装するためにアクションクラスが増えることで、生産性も落ちます。
生産性が落ちる要因は、下記だと感じました。

  1. クラスの増加によって、Javadocをリクエスト単位での説明で、知りたい機能単位の説明が出来ず、意図が伝わりづらい
  2. レビュー対象の増加
  3. 障害・バグ回収時の考慮漏れ

1は、なんともないと感じる人がいるかもしれませんが、結構問題だと感じました。
なぜなら仕様を説明する場合、リクエスト単位で説明しないからです。
機能の説明=JavaDocなので、JavaDocも書きづらくなります。
また、設計書もリクエスト単位で書いていたので辛い。本当は機能でまとめたい。
やれば出来なくもないけど、Strutsに影響されてか、その考え・発想がないのかもしれない。

Struts-config.xmlが面倒

コレがやばい。
何かと言うと、目にヤバイ。
パスをちょくちょく書くのだが、人がやるのでミスが生じる。
しかもそのミスが念入りに見ないと気づかないのだ。
優秀な人(笑)は、そんなこと起きないのだろうが、自分はうっかり八兵衛なので、よくパスをミスる。

f:id:suzaku0914:20160330225005j:plain

ミスした時は、「コイツはうっかりだぜ」って何度思ったことか。
コイツの悪いところは、実行しないと気づかないこと。
起動するにも時間的コストがかかるから、生産性にも影響を与える。
また、XMLというのがよろしくない。
助長な記述になってしまうので、XMLStruts-Configはお互いに悪影響を与え合い、開発を苦しめていると感じました。

もういいんだよ・・・・

Strutsは、そもそも開発者にやさしくない!
もういいんだよ。
もういいの。
もう自分を責めないで。。。
Strutsは生産性が低くて当たり前。すべて自分の所為にして、自分を追い詰めないで!

f:id:suzaku0914:20160330225946j:plain

生産性が低いのは、すべて自分が悪いと思わないほうがいい。
きっと原因は他にもあって、要因がいろいろ重なっているはず。
とはいえ、最低限の努力はしましょう。 ショートカット覚えるとか、Strutsの動きを理解するとか。
動きを知ることで障害対応がある程度楽になるはず。
ショートカットも覚えれば違う現場でも役に立つはず。

それにしてもストレスが溜まった。
ストレスとのつきあい方を学びたいなぁ~と思った今日このごろ

他の人は?

他の人はどうかんじるのだろうか?
コメントで教えてもらえると嬉しぜよ