Javaで生産性低下？

はじめに

オブジェクト指向（OO）による開発はソースコードの再利用性を高め、変更にも強い（と言われている）ことから Webシステムでも Javaによる開発案件が増えてきています。

が、しかし！

自分を含め、結構あちこちで ASP（VBScript）や Perlといったスクリプト言語ではありえない部分でハマッたという話を聞きます。今回は、なぜ Javaではまるのかを考えてみます。

注意！
筆者は特にJavaに恨みを持っているわけでも、OOが嫌いなわけでもありません。
OOはシステム開発には重要な概念です。筆者はスクリプト言語でもOO的開発を心掛けています。

そもそも、なぜ Javaを使うの？

• 「オブジェクト指向だから生産性が高い」と信じられているから
• 「オブジェクト指向だから再利用ができる」と信じられているから
• Tomcatなど、優れたフレームワークがあるから
• 発注者が「Javaで開発してね」って言ったから

Javaのここがダメ

きっちり設計できない or ブラッシュアップしてない

開発言語が何であれ、テキトーな設計は NGなのですが、特に OO言語は一番最初の分析・設計でつまずくとかなり痛いです。

インクリメンタル手法で絶えず設計もブラッシュアップしていればいいのでしょうが、OO的分析・設計にある程度精通していないといくらリファクタリングしてもゴールにたどり着けないというのも事実です。

で、結局納期優先で「Javaによる構造化プログラミング」が横行してしまうのです。

• 分析・設計は有能なメンバーを専任に据えよう
• リファクタリングできない（しない）のならパッケージ→クラスというトップダウン開発も検討しよう

コンパイルが必要

Javaの場合、基本的に開発者のマシンで一度コンパイルし、動作をチェックしてからサーバにアップロードします。コンパイルには最低でも数秒、ちょっとボリュームが大きくなると数分かかります。

コンパイルが終わってから、隣の人から必要なファイルを修正していたことを知らされたり、自分のソースでタイプミスを見付けたら、もう一度コンパイルし直しです。

スケジュールに余裕があれば笑って済ませられる問題ですが、リリース直前の切羽詰った状況では、トラブルの元にもなりかねません。

特に Tomcatフレームワークを使っていると、ちょっとした修正でもアプリケーションサーバの再起動が必要となることがあり、作業が完全に止まります。切羽詰った状況にもかかわらず作業が頻繁にストップすれば、発狂する人が出てくるのは当然です（この点について指摘する記事が見当たらないのは誰もが隠したがっているから？）。

• 発狂しそうな人がいたら、ローテーションで作業するようにしよう

ドキュメントがない（作らない）

1クラス 1ファイルという考え方（仕様）はもちろん悪くはないのですが、クラス数が多くなってくると、各クラスが何をやっているか、特に自分以外の人が開発しているクラスは何物なのかを理解するのが面倒になってきます。

Javaには「javadoc形式」というルールがありますが、ともすると後回しにして結局作らないため、「急いでいるから」という理由で似た仕様のクラスを複数できあがることがよくあります。

• 共用クラスは作る前に同じものがないか確認しよう
• 常に最新のドキュメントにするための人をアサインしよう

単体テストがしやすい

「テストファースト」という考え方とJUnitの登場で単体テストを積極的に進める向きがありますが、全てのクラスが単体テストにパスしたからと言って、結合テストにパスするわけではありません。

単体テストがしやすい分、それだけに固執してしまいがちなので注意が必要です。

• 単体・結合テストをどう進めるかを始めに決めよう
• 単体テストよりも、結合テストに時間をかけられるようにしよう

策に溺れやすい

Javaを取り巻く環境は日々大きく変化しています。その象徴が「フレームワーク」と「ツール」です。雑誌を見れば様々なフレームワークやツールが紹介されていて、どれもこれも「自分たちを使って〜」と叫んでいるように見えます。

その叫びに反応し、技術志向のリーダーは「よし、今回は○○を使ってみよう」と言ってしまいがちですが、今回のプロジェクトに、本当にその○○が必要なのかという検証をしている人はどれだけいるでしょうか。

実験的に使ってみて、ダメだと思ったらすぐに慣れた方法に切り替えることを計画に含めていないと、予期せぬ落とし穴に開発チーム全員がはまることになります。

• やり直しがきかないプロジェクトでは慣れない道具は使わないようにしよう
• どうしてもやってみたいなら、最初は小規模プロジェクトで実験しよう
• 必ずリカバリ策を立てておこう

おわりに

Javaは、継続的にバージョンアップや機能追加を行うタイプのシステム開発に向いています。ただ、それは設計担当者や中核となる開発メンバーが変わらない、という前提の下でのみ実現します。

どれだけ優秀なエンジニアが最初に設計をしたとしても、後任がその思想をきちんと理解せずにバージョンアップを進めると、あっと言う間に設計が破綻します。それを再度リファクタリングするには多大なコストと時間がかかることを忘れてはなりません。