ソースコードがスパゲッティ、仕様書もありません！

お客様とお話をしていると、よくソースコードが『スパゲッティ』とか、『グチャグチャ』、『つぎはぎだらけ』といった言葉を伺うことがあります。  IT用語辞典によると、スパゲッティコードとは『命令の実行順が複雑に入り組んでいたり、遠く離れた関連性の薄そうなコード間で共通の変数が使われるなど、処理の流れや構造が把握しにくい見通しの悪い状態になっているプログラムのこと』となっており、可読性／保守性が低い状態のソースを指しています。

 このようなソースになってしまうのは、なにもPowerBuilderに限らないことですが、主な理由としては、

• 古いバージョンでの頻繁な仕様変更／機能追加
• メンテナンス／リファクタリングをしていない
• 開発規約がしっかりしていない
• 継承機能を過度に使用して先祖・子孫階層が深くなっている
• 便利な機能を使用せず力技で開発している

などが挙げられます。  実際、PowerBuilder10以降でのUnicode対応に躊躇してマイグレーションをせず、古いバージョンが使い続けられていることがありますが、機能改修は頻繁に行われていたりします。  しかしこの機能改修では、マイグレーションのようにソース全体を見ることがなく、ソースの確認や対応が部分的／局所的になりがちです。  そしてそれが蓄積することで『スパゲッティ』になってしまう、といったことはよくあることです。

しかも、この状況に輪をかけてしまうのが、

• 全てを分かっているPowerBuilder技術者がいない
• メンテナンスされた仕様書がない

といった状況です。  いくらソースの中身がごちゃごちゃしていても、全てを分かっている技術者がいたり、全てが記載された仕様書があれば、まだよい方かもしれません。しかしこれらが揃っていることは稀で、極端な言い方をすれば、ソースがブラックボックス化してしまっている状態になります。  このような状態でマイグレーションをすると、下記のような弊害が発生します。

• 使用していない画面や機能までマイグレーションして余分な工数がかかった
• リファクタリングしていない部分がマイグレーション後に逆に不具合の原因になった
• （PowerBuilder技術者がいないから）マイグレーション中に出た課題の修正方法の検討に時間がかかった
• （仕様書がないから）現新比較テストで発見された不思議な挙動について調査に時間がかかった

この辺りのお話は PowerBuilder技術者様、出番です！でご紹介していますので、こちらもぜひご覧ください。

『スパゲッティで技術者も仕様書もない』ことから発生するソースのブラックボックス化。この状況を防ぐ手段のひとつとして、マイグレーションを定期的に行うことはとても重要です。  なぜなら、ご存知の通り、マイグレーションはソース全体を見ることのできる絶好のチャンスだからです。  実際にマイグレーションの際には、

• 使用していない不要な画面
• 潜在バグ
• リファクタリングした方がよい部分
• これまでの部分的／局所的な対応が及ぼしている悪影響

などが数多く発見されます。  このため弊社では、マイグレーションを『ソースの棚卸し』として捉え、お客様にはマイグレーションのタイミングでメンテナンス作業を行うことをおすすめしています。  『ソースコードがスパゲッティ』と言うと、メンテナンスをこれまでほとんどしてこなかったことを証明してしまうようなものなのかもしれませんが、マイグレーションの検討を始めること自体が、現状を改善するための第一歩となりますので、どうぞお気軽にご相談ください。  きっとマイグレーションによって今後のアプリケーションの運用保守についても新しい展望が広がることと信じております。

マイグレーション