ながれです。
今回は、新たに配属されたプロジェクトの既存システムを把握する方法について。
新規開発案件ではなく、既存システムの機能追加・改善案件に配属された際に
環境構築の次にやらなければならないのが「既存システムの把握」です
機能を追加・改善していくためには、既存システムのシーケンスを把握する必要があります。
しかし、プロジェクトによってはクラス図やシーケンス図が存在しない または 粒度が荒すぎてソースコードの該当箇所がわからない という場合もあります。
そんな、既存システムを把握する方法について今回はお話していきます。
既存システムを把握する方法
1 . 設計書を熟読し、ソースコードを眺める
これが最も早く、既存システムを把握する手段だと思います。
しかし、この手段が使えるのは以下の条件が揃っている時のみ
・設計書の粒度が細かい
・ソースコードにきちんとコメントが残っている
設計書の粒度は、設計書を読めばソースコードのどこで何をやっているかある程度理解できると言うレベルです。
この条件が揃っていれば、設計書を熟読する時間 > ソースコードを読む時間で素早く既存システムを理解できます。
2 . システムを動かしながら、ソースコードを熟読&ログを確認する
これは設計書の粒度は荒いが、ソースコードはある程度整備されている場合に適用できる手段です。
意外とこういうプロジェクト多いです。
「ソースコードが設計書だ！」
なんていう考えなんだと思います…。
この場合は、システムを実際に動かしながらソースコードを読んでログを確認しましょう。
オブジェクト指向言語であれば、デバッグログでメソッドのIN/OUTのログは見れます。
システムを動かして、吐き出したログを参考にソースコードを追いましょう。
3 . ソースコードにログなどを埋め込んで確認する
これは、設計書は粒度が荒いしソースコードにもコメントが全然残っていないような最悪の環境の場合に使えます。
要は2でお話したIN/OUTのようなログなどを自分で埋め込んでしまおう、ということです。
さすがに、システムの動かし方まで教えてくれない、と言うことはないでしょう笑
自身で過剰なくらいログなどを埋め込んで、動きを確認する他もう手段はありません…。
おわりに
いかがだったでしょうか？
今回は、私なりの既存システムの把握方法についてお話しました。
上記3つの手段共通で言えることとして、処理順序と何をやってるかがわかってきたら、簡単なシーケンス図のようなメモを必ず残しましょう。
一回分かっても、すぐ忘れてしまうので。
上記が既存システムの把握方法の全てではありません。
参考程度にしていただき、自分にあった把握方法を見つけていってください！
そういえば、もうすぐ4月かぁ…