おのたく日記 YouTubeも始めました→

■ J2EEへのパラダイムシフト

「IT Pro Java/J2EE : 【連載◎開発現場から時代を眺める by arton】第1回」を読んだ。

わんこは、J2EE特にEJBコンテナは終わったと思っているけど、このコラムは「J2EEへのパラダイムシフト」をうまく誘導できていると思った。

トラックに荷物を満載して皆でリヤカーのように引っ張って

[ 変化の足音が聞こえるか・・J2EEと開発プロセスをめぐるパラダイム・シフトより引用]

という例には笑った。確かに、新しい道具が手に入っても古い様式でプロジェクトを行っている例えとしては、ぴったりかもしれない。

最後の

設計者も，プロジェクト・マネージャも変化のただ中にいるのだ，ということを意識し率先して変化しなければならない。変化への対応とは，1970年代にウォーターフォールを採用し現在に続くIT資産を構築した先人が歩んだ道でもあるのだ

[ 変化の足音が聞こえるか・・J2EEと開発プロセスをめぐるパラダイム・シフトより引用]

というのは、耳に優しいようだけど、「明治維新で文明開化できたんだから、IT開花も出来るはず」という風にも聞こえる。文明開化で電話を使えるようになったような人々も、メイルを使えるようになるものだろうか?

ちょっと横道の道の話だけど、ITの歴史について、まとまっていて良かった。

1968年のダイクストラが起こしたgoto論争

ロイスが1970年に発表したウォーターフォールという開発プロセス

コッドのリレーショナルモデルは1969年

1994年にLinux バージョン1.0がリリース

GoFの『デザインパターン』の初版が1995年

Javaの登場は1995年

1996年にラショナルがUML(0.9)を発表

PMIが最初のPMBOK（注：プロジェクト・マネジメントの知識体系）を発行

マーティン・ファウラーの『リファクタリング』が1997頃に最初の姿を現し（出版は1999年）

JDBCとServletの概念はそれに先立つ1996年

J2EEとなるJavaエンタープライズAPIの発表も1997年

エリック・S・レイモンドの『伽藍とバザール』も1997年

XMLが1997年

SOAPの最初の仕様が1998年

1998年になるとラショナルがRational Unified Process5.0（RUP）を発表

1999年にケント・ベックのJUnitが登場しテスト・ファーストが具体化

1999年にJ2EE のAPI仕様1.0

[ 変化の足音が聞こえるか・・J2EEと開発プロセスをめぐるパラダイム・シフトより引用]

ここで、1995年のJava以前については知らなかったな。EJBの発表は1997年かもしれないけど、J2EEという言葉が出てきたのは1998年のJavaOneでは無かったかな?

■ ウォーターフォール開発の実装設計以降の工程にTDDを適用するという保守的なアプローチ

続きのIT Pro Java/J2EE : 【連載◎開発現場から時代を眺める by arton】第2回も読んだ。

TDD(Test Driven Developing)の意義を「テストを中心に据えることによるプログラムの品質向上」→「机上での実装設計という工程の不要化（と単体テスト段階の工数削減）」と捉えて説明している。

TDDで、異常系も含めてじっくりとテストしておいて単体テストが、さらっとできるようにして工数を削減するという戦略。

この中で、昔の事を知らずに不思議に思っていた事がいくつか解けた。

COBOLで、ネームスペースがグローバルなもんだから「プログラムで使用する要素の目録化」のために「モジュール名，プロシージャ名，変数名などの記号化された名称（「XA-001-0023Z」のような分類化された名称）を導出」が、されていたのね。

なんか、昔の残骸でよく出てくる「モジュール」って何かと思っていたんだけど、もしかしてCOBOLだと一つのファイルだったりするのか?

さらに実装仕様書は，システムの置き換え時に重要な意味を持つ。実装仕様書さえあれば，ソース・ファイルが散逸しようと，プログラミング言語を変えようと，いつでもソースコードを再作成可能だからだ

[開発現場から時代を眺めるより引用]

オープンソースだったりすると「ソースが命でソース読め」ってことでCVSなどのソース管理ツールが重要だったりするのだけれど、昔の人々がソース管理ツールより仕様書を大切にする理由が分かった。

次の「IT Pro Java/J2EE : 【連載◎開発現場から時代を眺める by arton】第3回」では、TDDを利用する場所として、怪しいミドルを使いトライ・アンド・エラーが必須なオープン系の開発でリスク低減のために、一度動かしてみるTDDが良いとしている。

「実装（＝設計）開始前から全体のコード量や不具合摘出件数を見積もることはもはや不可能」という言葉には、ちょっとショッキングだった。

でも、自分でオープン系の開発でも「えいや」ってコード量を算出できているような気がしている。これは、かなり職人的な勘であるというのも確かだけど…　否定するまでもないな。

最後のミドルウェアの更新によりバグが無くなる等して進化するので、常に保守による更新が必要で一度納品したものが、恒久的でないというフレーズは、忘れてはいけないと思う。

■ 個人情報をどうやって守るか?

人情報を保護する＝個人情報の漏えいをしない＝情報漏えいは内部犯行が多い＝社員教育でモラルを高めれば情報漏えいしない

[IT Pro 記者の眼 : どうやって個人情報を守りますか？より引用]

個人情報保護であれば、“出来心を封じるシステム”で十分だけど、会社は「社員は素晴らしいから教育しておけば完璧」「やばい奴はしかればOK」と思っていることが多いんだよね。

複雑だったりして、まもれないルールは、結局ダメなルールなんですけどね〜

この複雑な時代には、ルールが多すぎるのはダメっていうこと。