Java初級・中級から上級への階段 ~アーキテクトへの道
「フレームワークやORMも使いこなせてるし、あと何が必要?」
「デザインパターンとか学べばいいのかなぁ?」
プログラミングの学習って、
- 言語の文法など基礎知識を学ぶ
- フレームワークやライブラリの使い方を学んでアプリを作れるようになる
って段階があると思います。2まで来るとふつうに仕事できる人になります。
では、この次のステップは何でしょうか?
それは、アーキテクチャを設計できるようになることです!
私はこれまでに10年ほどJavaで業務システム開発をしてきました。経験を積んでいく内に、システム全体のアプリケーションアーキテクチャを設計・実装するようになりました。
そんな経験を踏まえて、「Java中級から上級への階段」を紹介します。
Contents
まず、初級・中級・上級の定義をしてみます
初級
Javaの文法やJDKの主要なクラスライブラリ、Servlet、JSP、JDBCを覚えて使えるようになってきたという段階が初級かと思います。
企業の新入社員研修で教えるような内容を理解した段階です。
中級
StrutsやSpring、JSF、Play、Wicketなどのフレームワークをどれか一つ覚えて使えるようになった段階が中級かと思います。
単独で現場の仕事ができるレベルです。
上級
プロジェクトの特性に合わせたフレームワークの選定・実装ができるレベル。いわゆるアーキテクトってやつです。
中級までは知識を修得すればいいですが、上級は知識を応用してプロジェクトに合わせたアーキテクチャ設計・実装ができなくてはなりません。
どうすれば、できるようになるかというと、
代表的なアーキテクチャ・デザインパターンを学ぶ
Webアプリケーションフレームワークの多くはMVCアーキテクチャです。
プログラムを
- Model(ビジネスロジックやデータ)
- View(表示)
- Conrtoller(制御)
に分けます。
デザインパターンはフレームワークの理解に役立ちます。
フレームワークにはデザインパターンがよく使われているからです。
例えば、Struts1のActionクラスやActionFormクラスにはStrategyパターンというデザインパターンが適用されています。
また、プロジェクトでStrutsを使う場合はActionクラスを継承しプロジェクト用のBaseActionクラスのようなものを作って、プロジェクトで開発する全Actionクラスはこのクラスを継承するという設計をする場合が多くあります。これはTemplate Methodパターンというデザインパターンです。
public abstract class BaseAction extends Action { public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { doExecute(mapping, form, request, response); } protected abstract ActionForward execute( ActionMapping mapping, ActionForm form, // ★ここに前処理を書くことができる。(後で追加する場合もここに追加するだけでロジックに追加できる) //子クラスへ処理を委譲 HttpServletRequest request, HttpServletResponse response); //ここに後処理を書くことができる } public class ItemCartAction extends Action { protected abstract ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { //ショッピングカート画面のロジックを実装 } } public class UserEditAction extends Action { protected abstract ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { //ユーザー情報変更画面のロジックを実装 } }
★がポイントです。★の所に例えば、アクセスログ出力のコードを追加するとUserEditActionが動作する時もItemCartActionが動作する時にも、アクセスログ出力がされます。
一か所にコードを追加するだけで全Actionへと変更を反映させることができるのです。これが、Template Methodパターンのメリットです。
Struts1のように古いフレームワークを使う場合にはTemplate Methodパターンが多用されていましたが、最近はそうでもありません。
フレームワークが元々持っている機能を使えば済むからです。
AOPという概念があります。AOPとはAspect Oriented Programming = アスペクト指向プログラミングです。
超おおざっぱに説明すると、AOPを使えばメソッドの前と後ろに任意のロジックを実行させることができます。
ですから、最近のフレームワークを使う場合には、プロジェクト用に凝った基底クラスなどを作らずにフレームワークをそのまま使うだけで済む場合も多いので、時代によって使う技術要素は変わるということです。
とはいえ、ここまでで説明したデザインパターンの知識はソフトウェアを設計するうえで発想のヒントとなるので学んでおいて損はありません。
今どきのアーキテクトはフレームワークを自作しない?
古いJavaプロジェクトのメンテをすると、いわゆるオレオレフレームワークを見かけることがあります。
- 素のServletの基底クラスを作って継承させる
- 自分でコントローラークラスを作って独自仕様のActionクラスのようなものに処理を委譲する
みたいなやつです。
昔はよくありましたが、最近はめっきり見かけなくなりました。
以下のような理由が考えられます。
- オレオレフレームワークを実装する時間が無駄。オープンソースのフレームワークの方が優秀
- オープンソースのフレームワークの方が本やWebサイトなどの技術情報が豊富で学習コストが低い
- オープンソースのフレームワークはバージョンアップやバグフィックスがされるが、オレオレフレームワークは自分でメンテしなければならない
よって、オレオレフレームワークは特別な理由(そのプロジェクトに合った既存のフレームワークが見つからない等)がない限り実装するべきではありません。
Java上級者の仕事
ここまでの話を踏まえてJava上級者の仕事を考えてみましょう。
1. プロジェクトに合ったフレームワークを選定する
先ほども述べた通り、オレオレフレームワークを実装するのではなく、既存のフレームワークの中からそのプロジェクトに合ったものを選定します。
「プロジェクトに合っているか?」という観点は、「システムの特性に合っているか?」ということだけでなく、
- 人員を集めやすいか
- 人員がすでに決まっているのであれば、その人員が使いこなせる難易度か
も考慮します。
2. 開発のガイドラインを作成する
フレームワークを使うとモジュール分割の仕方は決まりますが、モジュールの中でどのようにロジックを実装していくかには自由度があります。
各人の判断で実装していては、プロジェクト全体でバラバラな実装となってしまいます。
そこで、ガイドラインを作成します。
例えば「コントローラーにはDBアクセスのコードを直接書かずモデルの中に書く」のようなルールです。
3. サンプルコードを提供する
ガイドラインだけでなく、そのガイドラインに従ったソースコードのサンプルがあると、誤解なくスムーズに意図が伝わります。
言葉で説明しているのを読むよりも、コードを読んだ方が早いということはよくあります。
それにサンプルコードを流用することで、一からコードを書く手間を省くこともできます。
そんなわけで、これらを実践していけばJava上級者へとステップアップしていけると思います!