大量生産される新卒デビューJavaプログラマがぶつかる壁

ちょっと前にはてブで人気だったこの記事。

■Javaスクールの危険

私のような新卒でIT業界に入ってきてJavaでプログラムを覚えた人間、即ち大量生産されるJavaプログラマは、恐らく以下のような状況にある or あったと思われる。

このエントリは、

大量生産されるJavaプログラマは業務上アルゴリズムでヒーヒー言う機会が少ない。分岐とループだけ分かればビジネスロジックの肝である「業務ルール」は表現できてしまうことが多いので、ソフトウェアの品質を高める問題解決アプローチの重要性を叩き込まれることが非常に少ない。Javaの主戦場であるWEBアプリではその傾向が強く、「プログラムで表現できる幅」が広がらないと感じている。しかし、ちゃんとしたアルゴリズムを勉強しないとコードで表現できる幅を広げることは難しいので、みんながんばろう！

という話です。

文法が分からないと文が書けない

とにかく覚えたのは「Javaでプログラムを書くための文法」だった。

お決まりのSystem.out.println("HelloWorld")に始まって、for,while,if,switch・・・といったものをまず覚えた。変数についてはintとかStringとかまー色々あるのね的に考えていた。とにかく文法を学ばないとコンパイルに通らない。コンパイルできないと実行できない。それが死活問題だった。コンパイルが何をやっているのかもよく知らなかったし、環境変数のPATHなども知らなかった。

その次に苦労したのがmain以外の関数の書き方だった。何しろ「戻り値」と「引数」が全然わからなかった。returnって何処で書けばいいのだろうかと真剣に悩んでしまったほど、私はプログラムの世界がわからなかった。なので、

class Test01 {

	public static void main(String[] args) {
		Test01 test01 = new Test01();
		test01.Message(args[0]);
	}
	
	void Message(String message) {
		System.out.println(message);
	}

}

上記のようなプログラムが書けるまで、１ヶ月ぐらいかかった。

1. main関数はstaticのため、newしてオブジェクトを参照してやらないとコンパイル通らない。
2. 関数というものが、インプットがあってアウトプットを返すものと体でわかるのに時間がかかった。
3. 修飾子とか型とか引数とか一気に覚えたので消化不良を起こした。

などの理由だった。特にstaticのところでは苦労した。

Javaは文法が複雑すぎる件について

コンストラクタが出てくる頃から、上記のスレを立てたいぐらい、ますますJavaの文法がわからなくなっていった。この頃から同期でも脱落者が出始めた。いくらテキストを読んでも、概念的で抽象的な説明ばかりで何がどうなのかさっぱりわからん。プログラム上で全く表現できない。クラスとインスタンスについても、鯛焼きの型がクラスで鯛焼きがインスタンスなのであるみたいな説明を聞いて「ふーん」という感じで理屈だけは覚えたが、コンパイルを通すのには全く役に立たなかった。

結局、

• インスタンスを作るにはnewするとできるらしい
• staticメソッドからメソッドを呼ぶには、インスタンス名.メソッド名とやらないとコンパイルに通らない
• とにかくインスタンスを参照することでメソッドや変数にアクセスできるらしい

などの「コンパイルを通すだけの知識」が何よりも先に来た。

JavaDocにサーブレットにJDBC・・・

なんとかJavaの文法を覚えた後に待っていたのが、WEBアプリとDBだった。

またしてもここでサーブレットやJSPなどの文法を覚えさせられることになる。この頃から使うAPIの量もグンと増え、益々ワケがわからなくなっていった。「とにかくこーいうものなんだ」ということで、ひたすらネットや書籍のサンプルを読んではコピーしてナンボ。JavaのAPIドキュメントが何を意味しているのかがやっとわかってきた。importしてnewすればこれらのメソッドが使えるのかーぐらいに。

とにかくJavaという言語は、POJOから逸脱すると異様にめんどくさくなる。私の新人時代はそれにキャッチアップするだけで精一杯だった。

Javaプログラマデビュー

Java案件の多くはWEBアプリの案件だろう。私もWEBアプリ以外のJava案件に携わった事がない。だが、普通のWEBアプリで所謂アルゴリズムについて学べるような機会はかなり少ない言って良いだろう。WEBアプリは、

1. 画面からリクエストデータもらう
2. なんか処理する
3. DB問い合わせ or 更新を行う
4. レスポンス返す

という流れ。プログラム上大きく違うのはなんか処理する、ってとこだけ。なので、コードで表現できる幅の奥行きが狭いと思うことが過多ある。

なんか処理する、というのはビジネスロジック等のこと。ビジネスロジックはビジネスルールの表現を主に求められる。ソフトウェア工学を知らない、私も含めた大量生産されたイマイチなプログラマは、分岐とループだけで何とかしようとするし、実際何とかできてしまうことも多い。デザインパターンを適用した設計になったとしてもその適用された具象クラスのロジックがグダグダってことはよくある話である。オブジェクト指向とコード品質は基本的に何の関係も無い。補完的な関係ではあるけれども。

また、ビジネス層以外は概ねWEB層とDB層との絡みだけであり、最近はフレームワークでめんどい所が隠蔽されているので、POJOしか書けないプログラマでも無問題。DB接続する部分を担当するけど、S2DaoのようにDBのめんどい所をラップしてくれているフレームワークも出てきているので、基礎文法だけは知ってますよぐらいのプログラマで十分。WEBアプリにしてもサーブレットレス化が進んでるし。

もっかいまとめ

新卒デビュープログラマは、まずJavaの難解な文法を覚えるのでアップアップになってしまいがち。そしてその文法だけ覚えてしまえばJVMのおかげでクラッシュするようなコードにヒヤヒヤする経験が無いので、コードを書くことそのものは簡単。よって、良いソフトウェアを作るアプローチを会得できるかどうかは、言語仕様の壁でもあるのだが、別問題になってしまう。それが「Javaの危険性」であると言えるのではないか、と。

壁にぶつかった憂鬱なJavaプログラマの皆さん、今こそコンピューターサイエンスの世界に飛び込むベストタイミングだと思います。お互い頑張りましょう。