お客様とお話をしていると、よくソースコードが『スパゲッティ』とか、『グチャグチャ』、『つぎはぎだらけ』といった言葉を伺うことがあります。 IT用語辞典によると、スパゲッティコードとは『命令の実行順が複雑に入り組んでいたり、遠く離れた関連性の薄そうなコード間で共通の変数が使われるなど、処理の流れや構造が把握しにくい見通しの悪い状態になっているプログラムのこと』となっており、可読性／保守性が低い状態のソースを指しています。
このようなソースになってしまうのは、なにもPowerBuilderに限らないことですが、主な理由としては、
などが挙げられます。 実際、PowerBuilder10以降でのUnicode対応に躊躇してマイグレーションをせず、古いバージョンが使い続けられていることがありますが、機能改修は頻繁に行われていたりします。 しかしこの機能改修では、マイグレーションのようにソース全体を見ることがなく、ソースの確認や対応が部分的／局所的になりがちです。 そしてそれが蓄積することで『スパゲッティ』になってしまう、といったことはよくあることです。
しかも、この状況に輪をかけてしまうのが、
といった状況です。 いくらソースの中身がごちゃごちゃしていても、全てを分かっている技術者がいたり、全てが記載された仕様書があれば、まだよい方かもしれません。しかしこれらが揃っていることは稀で、極端な言い方をすれば、ソースがブラックボックス化してしまっている状態になります。 このような状態でマイグレーションをすると、下記のような弊害が発生します。
この辺りのお話は PowerBuilder技術者様、出番です！でご紹介していますので、こちらもぜひご覧ください。
『スパゲッティで技術者も仕様書もない』ことから発生するソースのブラックボックス化。この状況を防ぐ手段のひとつとして、マイグレーションを定期的に行うことはとても重要です。 なぜなら、ご存知の通り、マイグレーションはソース全体を見ることのできる絶好のチャンスだからです。 実際にマイグレーションの際には、
などが数多く発見されます。 このため弊社では、マイグレーションを『ソースの棚卸し』として捉え、お客様にはマイグレーションのタイミングでメンテナンス作業を行うことをおすすめしています。 『ソースコードがスパゲッティ』と言うと、メンテナンスをこれまでほとんどしてこなかったことを証明してしまうようなものなのかもしれませんが、マイグレーションの検討を始めること自体が、現状を改善するための第一歩となりますので、どうぞお気軽にご相談ください。 きっとマイグレーションによって今後のアプリケーションの運用保守についても新しい展望が広がることと信じております。
マイグレーション
