私の部署は現在、かなり大きな COBOL コード ベースを維持するというタスクの責任に直面しています。ビジネス ニーズに対応するために新しい機能を追加する方法を考えています。最近は COBOL プログラマーを獲得するのが難しく、Java や C# などの最新の言語を使用することで生産性が向上すると考えています。
次の 4 つのオプションがあると考えています。
私たちにとって最良の選択肢は何だと思いますか、またその理由は何ですか?
確かに、問題はあなたのニーズに固有の答えを作る cobol に関係しています.
私は、オプション 2 を選択した 3 つの会社で働いてきました。2 つ目は、新しいシステムの支払いをしようとして破綻しましたが、古いシステムからの収益しか得られませんでした。
オプション #3 のもう 1 つの要因は、何年にもわたって行ってきたすべての古いバグ修正を保持できることです。書き直しを行うたびに、バグがどんどん増えていきます。その理由の 1 つは、書き直しをすばやく完了させたい場合、新しいなじみのない言語で書くことになる場合、およびすべての新しいコードにバグがある場合です。
古いアプリの論理チャンクをリファクタリングして置き換えます。最終的には、光沢のある新しいアプリができあがります。新しいものへの最も安全なアプローチを取得するには、GUI から始めます。その上、アプリを新しいものに書き直すまでには、さらに新しいものが最もクールになり、新しいアプリは時代遅れになり、同じ質問をもう一度投稿することになります!
これはオプション 3 のバリエーションです。
Microfocusは、COBOL が Web サービスと対話できるようにする Enterprise Server と呼ばれるツールを提供します。
COBOL プログラム A と別の COBOL プログラム B があり、A がインターフェイス セクションを介して B を呼び出す場合、このツールを使用すると、B のインターフェイス セクションを Web サービスとして公開できます。
次に、プログラム A に対してクライアント プロキシを生成すると、A は Web サービスを介して B を呼び出すことができます。
もちろん、B には Web サービスがあるため、他の種類のプログラム (コマンド ライン、Windows アプリケーション、Java、ASP など) もそれを呼び出すことができます。
このアプローチを使用すると、COBOL ビジネス エンジンを利用しながら、ASP のようなものを使用して、GUI を最新のブラウザー ベースのアプローチに移行することができます。
そして、適切な Web サービスのセットがあれば、これらを長期的に COBOL から離れる方法を提供する新しい開発に使用できます。
完全な書き換えを試みる場合は注意してください。多くのソフトウェア会社にとって、これがうまくいかない例はたくさんあります。Netscapeはその代表的な例です
80/20 ルールに従います。クライアントと一緒に座って、アプリの 20% が 80% を使用する仕様を作成します。それを現代のシステムで書いてください。次に、少数の特殊なケースのために古いシステムを維持するか、新しいシステムを肉付けするときに段階的に廃止します。
古いコードを 100% 書き直そうとしないでください。それはばかげています。最良のシナリオは、古いシステムの完全なポートを持っていることです。最悪のシナリオは、多くの時間とお金を費やして新しいシステムに障害が発生し、古いシステムを使い続けていることです。
システムを移植するだけでなく、システムを改善するために時間と労力を費やしてください。最も重要な部分を移植した後、その時間を使って特殊なケースを再検討してください。
オプション＃2と＃3が最良の選択です。COBOLアプリケーションがデータをSQLDBまたはその他の適切な形式で格納している場合は、最も安価で簡単なソリューションである最新の言語から簡単にアクセスできます。
そうでない場合は、再構築中に重要な新機能を実装するスタッフをスタッフに配置する必要があります。ただし、古いコードベースの新機能を本当に重要なものだけに制限するようにすべての人に依頼することをお勧めします。
長期的には、COBOLの保守はますます困難になります。長く待つほど、難しくなります。
アプリケーションを段階的に移行しますか?
他のコードを COBOL に接続し、変更が発生するにつれてコンポーネントを徐々に書き直す方法はありますか? すべてを取り除くことはできないかもしれませんが、それは本当に重要ですか?
既存のコードを書き直すことは、一般的には悪い考えです。これは非常にリスクが高く (たとえば、誰かが依存している理解が不十分な機能を壊すリスク)、ほとんどの利害関係者が目にする有用なものを何も達成せずに多くの時間を費やします。
必要に応じて、有能なプログラマーが COBOL を学習できないと思い込まないでください。プログラミング言語はさまざまです。(たとえば) C++ や Java の有能な人を雇えば、彼らは COBOL を学ぶことができます。
私は自分で古いシステムを新しいシステムに移行しました (ただし、規模はかなり小さくなりました)。
私たちは、クライアント/サーバー システム (小規模な社内作成のレポート システム) に対して、「段階的な置き換え」(#2) アプローチを使用して非常に成功しました。「プロキシ」アプローチを使用して、実際にはひねりを加えてそれを行いました。
このアプローチは多くの柔軟性をもたらし、古いコードに触れることなく新しいものを実装することができました. 切り替えは 1 年以上続き、アプリの最後の部分だけが新しいシステムに移行されました。これは、古いサーバーが廃止予定の専用の老朽化したハードウェアで実行されていたためです。
すべてが移行されたとき、私は実際にサーバー ルームに行って、古いサーバーを個人的にシャットダウンしました。それは楽しかった ：-）。
ちなみに、この「段階的な切り替え」アプローチにより、新しいシステムにログを実装して、どの機能がどのくらいの頻度で使用されたかを判断することもできました。そうすれば、クライアントが使用しなくなったことが判明したため、古いサーバー機能の一部を廃棄することができました。これは、「プロキシ」アプローチの大きな利点でした。
私は古いコードを維持し、Microfocus/AcuCOBOL の優れた機能を使用して新しい機能を追加しました。GUI アプリケーションを実行し、「レガシー」コードから直接 .NET および Java を呼び出すことができます。
バックエンドが機能しているのに、なぜバックエンドを壊すのですか? 私が勤めている会社では、機能しているバックエンドを維持し、疲れたフロントエンドを置き換えるというソリューションを採用し始めています。
そのような解決策があるので、私の選択はオプション＃3になると思います。
適切なコースを決定するにはデータが不十分です。
多くの人が特定の状況に応じて適切な答えを出していますが、正しい答えは実際には会社のビジネス状況によって異なります。
既存のロードマップ、デリバリー コミットメント、サービス契約、新機能の必要なリリースまでの時間などによって、状況に最適なものが決まります。
そうは言っても、多くの技術者の答えは 1 番であり、多くのビジネスマンの答えは 4 番です。提示されたものしか知らないので、おそらくリスクが最も低い #3 を深く調査するようにチームに働きかけます。#1 は失敗の実績があり、#2 はリソースが少ないだけの #1 です。#4 はおそらく長期的な解決策ではありません。ただし、この製品ラインを短期的または中期的に EOL にする場合を除きます。
私は古いアプリケーションを維持しますが、それでは、私はCOBOLプログラマーです...。
次のように、cobol を C# に変換するサード パーティ製アプリの 1 つを使用するのはどうでしょうか。
http://www.softwaremining.com/index.jsp
または、それを COBOL.net に移植する方が簡単なはずです。追加するものはすべて、他の .net 言語のいずれかである可能性があります。
正直なところ、ColdFusion 5 から PHP、ColdFusion 8 へのアプリケーションの「移植」を支援したことから、私は #1 を採用したいと思います。古いアプリケーションをそのままにして、開発をフリーズします。顧客と会って、古いシステムがどのように機能するか、または機能するはずだったかに加えて、新しい機能が何であるかを特定し、適切な要件ドキュメントを作成します。あとは構造と設計の詳細を残すだけで、アプリケーションに最適な言語とプラットフォームをインテリジェントに選択できます。
私が現在働いている場所では、代わりの .NET アプリケーションを構築している間、実際には古い CF アプリケーションを維持しています。ベース アプリケーションを完成させた後、.NET 担当者が作成しなければならないコードを想像できますか? そのため、開発を凍結することをお勧めします。
私は、レガシー アプリケーションを最先端のテクノロジに更新することを強く信じています (マネージャーはがっかりしました)。これは常に段階的なアプローチであり、必要な場合にのみ実施する必要があります。レガシー アプリケーションを継続して実行し、その目的を達成するように努めますが、その一部を新しいテクノロジで作成し、時間の経過とともに古いコードを段階的に廃止して新しいコードに置き換えます。私は常に、ビジネスにとってのメリットとコストを優先するようにしています。
アプリケーションがあまりにも緊密に織り込まれている場合、分離されたサービスを引き出すのを助けるために何人かの COBOL スクリプターを雇う必要があるように思えます。
これに注意してください: 元のレガシー コードのバグや癖が、ビジネスが依存する目的に役立つ場合があるため、他のコードが後で依存するエラーを修正することには注意してください。
別の解決策は次のとおりです。
コードを選択した現代の言語に翻訳します。
通常、これにはいくつかの大きなチャンクが含まれます。
このアプローチの主な利点は、何年にもわたってコード ベースにエンコードされてきたすべての厄介なビジネス コーナー ケースが保持されることです。ゼロからの書き直しの大きな問題は、蓄積された知識がすべて破棄されることです。
もう 1 つの利点は、煩わしい問題 (cobol アプリの保守) が楽しい問題 (自動言語翻訳) に変わることです。そのため、優れたプログラマーをプロジェクトに参加させるチャンスがあります。
ジム・デンバーのコメント
ある程度読みやすく保守しやすいコードに変換するトランスレータを書くのは非常に難しいのではないでしょうか? 私たちの問題は、COBOL アプリがメンテナンスの悪夢であることです。これが別の言語で同じ悪夢になることは望んでいません。
それがどれほど難しいかはわかりません。開始元のコードが通常の場合は簡単です。しかし、いずれにせよ、「$LANG で書かれた COBOL」になってしまいます。これは、メンテナンスの悪夢が修正されるまで、インクリメンタル リライトの開始点にすぎません。
これは、「ゼロから書き直す」および「COBOLで維持する」の代替手段にすぎません。コード ベースに蓄積された知識の価値が、インクリメンタル クリーンアップの予想コストを下回っている可能性があります。
私が知っているある会社は、まったく同じ質問に何年も悩まされていました。最終的に、彼らは COBOL アプリケーションをやめて、SAP に切り替えました。それを行うことは、完了するまでに数年を要した巨大なプロジェクトでしたが、うまくいきました。
COBOL の優れた点は、データ要件がコードの先頭に記述されていることです。また、COBOL が (比較的) 平易な BUSINESS 英語 (TXTSPKers を適用する必要はありません) を使用して記述されるように設計されていることも役立ちます。
もちろん、芝刈り機が一部のプログラマーよりも古い場合は、ソースを読ませることを忘れてください。彼らは泣き言を言いすぎます。
OpenVMS を使用している場合、BridgeWorksは、古いコードを少し変更して使用する Web アプリケーションの構築を支援する場合があります。