Windchill案件で
Eclipseを見ても
構成が分からなかった話

FIRST PROBLEM

Eclipseを開いた。
でも、何を見ればいいのか分からない。

案件に入って Eclipseを開けば、 ソースコード自体は見えます。

Javaのクラスもある。
JSPもある。
JavaScriptもある。

ただ、 ファイルが見えることと、 システムの構成が分かることは 全く別でした。

このクラスは どの画面から呼ばれるのか。

このメソッドが扱っているデータは 何なのか。

この処理の結果が Windchill上のどのオブジェクトに 反映されるのか。

Javaとして読めても、 業務として何をしているのかが 分からない状態でした。

WHY IT WAS DIFFICULT

普通のJavaだけを見ても、
処理の意味が分からない。

Windchillの案件でも、 開発言語としてはJavaを使います。

だから最初は、

「Javaの処理を追えば 分かるだろう」

と考えていました。

でも実際には、 Javaだけを追っても 分からない部分がかなりありました。

理由の一つは、 コードの中で扱っているものが 単純な画面データではなく、

部品、
文書、
属性、
製品構成、
BOM

といった PLMの世界のデータだからです。

メソッド名や変数名だけを見ても、 その業務上の意味が分からないと 処理全体を理解しにくい。

逆に、

「このオブジェクトは何を表しているのか」

が分かり始めると、 Java側のコードも 少しずつ読めるようになりました。

FIRST STEP

まず、画面から処理を追った。

ソースコード全体を 上から理解しようとしても、 ファイル数が多すぎます。

そこで、 自分が担当する機能について、

「この画面で操作したときに、 何が呼ばれているのか」

というところから 見るようにしました。

画面を操作する。

JSPやJavaScriptを見る。

そこから呼ばれている Java側の処理を探す。

さらに、 そのJavaクラスが どのオブジェクトを扱っているかを見る。

こうやって 入口から一つずつつなげていく方が、 自分には理解しやすいやり方でした。

OBJECT

次に必要だったのが、
オブジェクトと属性の理解。

コードを追っていると、 当然いろいろな値が出てきます。

ただ、 Windchillでは、

「この値がどこから来たのか」

を考えるときに、 オブジェクトと属性の理解が必要でした。

何のオブジェクトなのか。

そのオブジェクトは どんな属性を持っているのか。

どの属性を取得して、 どの処理に使っているのか。

ここが分かってくると、 コードの意味も かなり追いやすくなりました。

単純に、

「String型の値を取っている」

と見るのではなく、

「Windchill上のこの属性を取得して、 この判定に使っている」

と見られるようになる。

この違いはかなり大きかったです。

BOM / STRUCTURE

BOMが分かると、
処理のつながりも見えてきた。

Windchillを理解するときに、 もう一つ重要だったのが BOMや製品構成でした。

最初は、

Assy。
SubAssy。
部品。

と言われても、 それぞれがどういう関係なのか イメージできていませんでした。

でも、

「製品の中に構成があり、 その下にさらに部品構成がある」

という関係が見えてくると、 Windchillで扱っているデータの意味も 少しずつ分かってきます。

コード上で 親子関係をたどっている処理も、

Javaのリスト処理として見るのではなく、

「製品構成をたどっている」

と考えられるようになります。

このあたりから、 Windchillのコードが 単なる複雑なJavaではなくなってきました。

BOMについては、 別の記事でも詳しく整理しています。

BOM・Assy・SubAssyの関係を見る →

EXISTING CODE

新しく書くより、
既存コードを読む時間の方が長かった。

Windchillの案件で経験したのは、 ゼロから新しいシステムを 作る開発ではありませんでした。

すでに動いているシステムがあります。

既存の機能があります。

その中に、 新しい処理を追加したり、 既存機能を変更したりします。

そのため、 実装する前に、

「今どう動いているのか」

を理解する必要がありました。

似た機能はないか。

同じオブジェクトを扱っている処理はないか。

既存の呼び出し方はどうなっているか。

既存コードを参考にしながら、 少しずつ実装方法を探していきます。

この経験で、

既存システムの開発では、 コードを書く力と同じくらい コードを読む力が必要

だと感じました。

TRACE

分からない処理は、
呼び出し元と呼び出し先を追う。

処理を読んでいて 分からなくなったときは、

そのメソッドだけを ずっと眺めるのではなく、

「誰がこの処理を呼んでいるのか」

と、

「この処理は次に何を呼んでいるのか」

を見るようにしました。

呼び出し元を見ることで、 何を目的に実行されている処理なのかが 分かることがあります。

呼び出し先を見ることで、 最終的に何を変更しているのかが 分かることもあります。

さらに、

画面
↓
Java
↓
Windchillオブジェクト
↓
他システム連携

という流れが見えてくると、 一つの機能として理解しやすくなりました。

DEBUG / CHECK

読んで分からなければ、
実際の値を見る。

コードだけでは どうしても理解できないこともあります。

そういうときは、

実際に何が入っているのか。

どこまで処理が通っているのか。

どの条件で分岐しているのか。

実行時の状態を確認する方が 早いこともありました。

これはWindchillに限らず、 今でもよく使う考え方です。

WHAT I NEEDED

Windchill全部を理解する必要はなかった。

案件に入った最初の頃は、

「Windchillそのものを 理解しないと開発できない」

と思っていました。

でも実際には、 最初から全部を理解する必要はありませんでした。

自分が担当する機能について、

どの画面から始まるのか。

どのJava処理を通るのか。

どのオブジェクトを扱うのか。

どの属性を見るのか。

BOMや構成とどう関係するのか。

最終的にどこへデータが流れるのか。

ここまで分かれば、 担当機能の開発は 少しずつ進められるようになりました。

分からない範囲を 一つずつ広げていけばいい。

これはWindchill案件で 一番大きく学んだことの一つです。

AFTER THAT

PLMの知識より先に、
「既存システムの追い方」を覚えた。

振り返ってみると、 この案件で身についたのは Windchillの知識だけではありませんでした。

分からないシステムに入ったとき、

何から確認するか。

どこを入口にするか。

既存コードをどう追うか。

業務上の意味と コードをどう結びつけるか。

そういう 「知らないシステムへの入り方」を この案件でかなり経験しました。

その後、 別のシステムや 知らない技術に触れたときにも、

最初から全部を理解しようとせず、

自分が触るところから 一つずつ追っていく。

という考え方は かなり役に立っています。

SUMMARY

最初に必要だったのは、
Windchillの暗記ではなかった。

Windchill案件に入った当初、 Eclipseを開いても 何がどこにあるのか分かりませんでした。

Javaはある。

JSPもある。

JavaScriptもある。

でも、 それぞれが Windchillのどの機能につながっているのか 分からない。

そこから、

画面から処理を追う。

呼び出し元と呼び出し先を見る。

オブジェクトと属性を理解する。

BOMや製品構成と コードを結びつける。

実際の値を確認する。

そうやって、 少しずつ理解できる範囲を 広げていきました。