はじめに
XDDPでは、既存の仕様書が十分出ない場合、ソースコードから不足する情報を補う資料を作成する作業が必要としています。この作業を「スペックアウト」と呼びます。スペックアウトでは、ソースコードから何かを書き出す/描き出すことになるのですが、何をどのようにカクかを考えていきます。
カクこと
まず、カクという動作は2種類あります。文章で表現する書く、と図や表で表現する描くです。表(マトリクス)は文章も含まれますが、図的役割の方が大きいため描くです。スペックアウトでは、文章と図表の両方を利用しますが、図表への描き出しの方が重要と考え、スペックアウトでは何かを描き出すと表現したいと思います。
何を描いたか
1. 正常系のソースコード
もっとも容易なスペックアウトとして、ある制御の正常系のソースコードを抜粋して、文書にコピペすることが挙げられます。コピペ対象は関数名だけか関数内の処理全てのどちらかになります。実際の動作環境でバックトレースログを取得できれば、さらに容易にスペックアウトすることができるでしょう。正常系の処理フローをスペックアウトできると、ひとまず対象モジュールの骨格が見えてきます。そのため、開発チームに入ってきたばかりのメンバーがそのモジュールを理解する際に、行う作業として適していると考えます。対象モジュールの全体像の仕様書があれば、それを読んでもらいつつ、今後担当してもらう機能部分の正常系をスペックアウトしてもらえば、無駄がないと考えます。
2. フォルダ単位の機能説明
全体像が掴めないモジュールに対して、そのモジュールに含まれるソースコードフォルダをリスト化し、各フォルダごとの機能説明を付与した表を作成したことがあります。各フォルダに含まれるソースコード全てまたは多くを確認し、どのような役割を担っているか考え、それを文章にする必要があります。各フォルダごとの機能が明確であれば、容易なのですが、逆に不明確であれば非常に難しいです。私が実施した際は、1フォルダ内で複数の役割をもっていたり、1つの役割が複数フォルダに分散していたり、とカオスな状態でした。メリットとしては、そのモジュール全体の思想を把握する足がかりにできるということだと考えます。ただし、作業に時間がかかるので、なかなか実践しにくいと思います。
これまでに実施したものでぱっと思い出せるのは、この2つです。基本的に私が実施してきたスペックアウトはソースコードから対象にしたい処理部分を確認し、その関連部分をコピペしてまとめる、ということが多いです。
対象 | 方法 | 効果 | 利用場面 |
---|---|---|---|
正常系のソースコード | 関数名などを文書にコピペ | 対象モジュールの骨格が見える | 対象モジュール未経験者の初期作業 |
フォルダ単位の機能説明 | 各フォルダ内を確認し、役割を考え、文章にする。 | 対象モジュールの思想を把握する第一歩になる | リファクタリング時? |
おわりに
このスペックアウトは我流で、もっとスマートな方法であったり、別の観点などはないかと考えています。その際に思いついたのが、UMLでスペックアウトすれば良いのではないか、ということです。そもそもUMLの使い方として、リバースエンジニアリングがあるため、方向の1つとしてはあるはず。次回はUMLでスペックアウトすることを考えます。