くさい開発環境 Java

5月中に書き上げるつもりが月をまたいでしまいました。


いま触っているシステムを一言で表すなら***でできたジェンガと言ったところですかね。

以前なにかのセミナーで、「エリック・エヴァンスドメイン駆動設計を実践してみた」というような内容の発表をしていた方がうまい例えをしていました。

良い設計は分子模型のように、土台がしっかりしていて外に拡張可能である。

そうでない設計は往々にして、穴だらけでグラグラ、上にただ機能を積み上げることしか出来ないジェンガである。

なるほどと思いました。(本に書いてあるんでしょうか?)
いま触っているシステムはまさにこれ。

クソの上に何を乗せてもクソとは良く言ったもので、 本当にどんなに改修や機能追加を試みてもそこは臭くなってしまいます。これは精神衛生上とても良くないです。 私自身、スキルに自信があるわけではありませんし、やはりコーディングルールやフレームワークといった枠組みがないと、 どうしても「とりあえず動けばいい」だけのクソコードが出来上がります。 もし土台がしっかりしていたなら、私ももう少し良いコードが書けていると思うんですよね。(いいわけくさいですが、事実の側面もあるはずです。)

ここまで散々ディスったわけですが、具体的にはいったい何が、どこが臭いのでしょうか。


さて、前置きが長くなりましたが、今回は私がブログなどを読んで知った「これはJava(EE)アンチパターンだ」と思っているものを紹介致します。
(こちらと被る部分が多々ありますが、ご容赦ください。)

まずはこちら、これが一番の問題だと考えています。

1. JSPメソッド定義やロジックが詰め込まれている

私が何よりクソだと考えているのがこれです。長いファイルだと1万行に届き、行数を見ただけでそっ閉じです。 デメリットは色々あるのですが、順に見ていきましょう。

クラス化されていないため、メソッドやロジックのユニットテストが出来ない。

実際、半分以上の画面がクラス化されていない気がするので、それだけユニットテストが実施出来ていないことの証明です。

(そもそもテストは全て手動+Excelに結果記述なのでJUnitなんて使う気もないようです。)

これにより回帰テストが全く出来ないのがとても困りもので、メソッドをクラスに移動したり、利用されているクラスのリファクタリングを行おうとすると、それが知らぬ間に別画面に(絶対に)影響するのですが、それを全く検知出来ず、運用から電話がかかってくるんですね。
この流れが本当にクソ。リファクタリングのやる気を削がれたらもうどうしようもない。 そもそもが2003年とかに書かれて以降ろくなメンテもされないままツギハギな機能拡張が行われているので、その複雑さはネスト以上に深淵です。

可読性が落ちる。

JSPにロジックを書くと、当然ですがJavaコードとHTMLが混在します。私が触っているファイルは、HTML中に表示する段階になって初めて、 そこでデータを処理してHTML中で出力する、というふうにしていることが多かったです。 これはスクリプトレットと言いますが、これをやってしまうとJavaコードとHTMLが入れ替わり立ち替わり出現するので、その度に頭を切り替える必要が出てきます。また、コードもHTMLもそれぞれのインデントがあるのに、コードとHTMLが変わるタイミングでインデントも変わるので、目線の移動が発生しますね。長くコードを読んでいたのに、突然HTMLが出てきたり、その逆になったりすると、本来のインデントがどこだったかわからなくなり、上に戻る、なんてことも普通にあり得ます。

IDEのサポート能力が落ちる。

これはIDEによるのかも知れませんが、現在使用しているEclipseでは、自動補完のスピードが著しく落ちました。Javaコード以外のものも混ざっているため、解析に時間がかかるのでしょうか。他にも、エラーが発生するようなコードでも反応が無かったり遅かったりと不安定になりやすいです。

いわゆるMVCに則っていない。

MVCにおけるView(JSP)部分に、ModelやControllerにあたるコードが混ざり込んでしまうことになります。MVCパターンは、各レイヤの役割をはっきりさせ、互いの依存性を抑えることでメリットが生まれます。しかし、JSPにロジックを書いてしまう方法は、この全く逆になり、1つのファイルに役割が集中し、コードの再利用性が落ちます。

2. 命名規則やコーディングスタイルが統一されていない

命名の重要性は共通見解だと思うのですが、このプロジェクトではそうではないみたいですね。 コーディングスタイルはあまりかっちり決めてしまうのもかえって良くないと耳にしますし、Javaの基本的な規則が守られていれば十分ではないでしょうか。(つまり守られていない。クラス名頭文字が小文字だったりした。)

プロジェクト内Wikiなどがなく、プロジェクトで使用されている言葉や意味が個人の経験に基づいていて共有されていない。

命名規則については、業務システムでは特にしっかりと命名が必要だと実感しています。 業務ドメインの用語がとてもたくさんあって、しかも名前が著しく似ていたりするので、変数名が同じなのに別のJSPでは意味が違ったりします。 これが厳密に定義されていないため、触るファイルが変わるごとに頭を切り替える必要があります。また、修正する際などに、うっかり意味を思い込みで考えてしまい、あとで別の意味だったことに気づく、ということもざらです。

Javaの基本的なコーディング規約すら守られていないことがある。

これは頻度はそう多くないですが、見てしまったときは気が滅入ります。 特に上記のクラス名頭文字が小文字は絶句してしまいました。 他にもメソッド名に

isGet~

など動詞が重なっているものなど、いかにも適当につけてしまっています。

3. Gitによるソース管理やツールによる自動化が行われていない。

社内政治によって導入は難しいのですが、これらのツールは便利であると同時に必須スキルになりつつあるので、日常的に使える環境だと嬉しいですね。

SVNによって管理されているが、コンフリクトが起こることがある。

開発ブランチは特にバージョン管理されておらず、 また開発は複数チームにまたがっていて、しかも他のチームがどこを弄っているかはわからない(チーム間コミュニケーションはない)ため、 運悪く同一ファイルをいじっていると、コンフリクトが発生してしまいます。

SQLなどコード以外のバージョン管理がされていない。

SQL(DDL)などは、実行したらそのままで、変更が入る場合は

--2015/XX/XX Mod

のようなコメントを挿入することで管理しているようです。 これは本当にムダで、変更の都度「Gitでバージョン管理すべきだろ」と思いならがらコメントを書いています。

書いているうちに思いついたのはこれくらいですが、作業中はもっと色々な点について脳内で毒づいています。

「これは別にアンチパターンではないだろう」というところがあったら、教えて頂ければ幸いです。