望月様はじめまして、
小野 剛ともうします。COBOL でのXP実践に関連して:
>> Regarding [XP-jp:03260] COBOL でのＸＰ実践; Katsuya_Mochizuki@....jp adds:
> COBOLとVBを使用しての開発にてＸＰを取り入れられないかと
> 考えています。
> COBOLにての検討や実践の事例・考慮点などご存知でしたら
> お教えください。「止めた方が良い」というご意見でも結構です。
'Extreme Programming Examined' という XP 関連の論文集の、翻訳をやって
おります。 この本のなかに "Legacy to the Extreme" という論文があり、
COBOL で書かれたコード群を相手に XP に取り組んだ人の実践記があります。
その中からちょっと抜粋して見ました。
- 「変化のコスト」カーブを平らにする、というXP の戦略は、発達したソ
フトウェア工学的な知見を利用できる環境ではやりやすいが、COBOL コード
に囲まれたレガシーな環境では多少困難だ。だが不可能ではない。
- 「リバースエンジニアリングツールをどれだけ駆使出来るか」がカギとなった。
これはLMT(レガシーメンテナンスツールボックス)と呼ばれ、これと DocGen
を組み合わせることで、システム全体の構成や依存関係を視覚的に把握する
ことが可能となった。その基礎のうえにテストやリファクタリングを行った。
- また、COBOL 変数の型を推論する TypeExplorer [Deursen+1999c]も使用した。
これがないと、リファクタリング時での影響解析が出来ない。たとえば、今ま
で「英国ポンド」で表していた amount という型を、すべて「ユーロ」にする
という変更を行う場合には、TypeExplorer でまず amount と同じか同等な型と
なる変数を全てリストアップして、影響範囲を特定する作業が必要となる。
- レガシー環境での XP も、通常と同じように、
1. 変更要求からテストケースを書き起こす
2. LMT をもとに「下準備」のリファクアタリング(重複コードの削除など)
をしてテストを実行
3. 要求を満たすような変更を加え、テストを再実行
4. さらにリファクタリング、テスト、そしてシステムドキュメントの再生成
を行う
というステップを経る。違いは、イテレーション毎の生産性が低いことである。
[Deursen+1999c] A. van Deursen, L. Moonen. "Understanding
COBOL Systems Using Types." In Proceedings of Seventh Inter-
national Workshop on Program Comprehension, IWPC'99. IEEE
Computer Society, 1999.
私自身は COBOL での開発経験がないので、ちょっととんちんかんなことを書
いているかもしれませんが、何かの御参考になれば幸いです。
// Tsuyoshi ONO //
e-Communications Dept, Telecom & Service Company / SONY Corporation
email: ono@....jp
"Be completely flexible on how we get there, but be totally
uncompromising on where we are going." -- Martin Fowler