C ++でのIBMアセンブラー+ COBOLの書き換え
私は1972年に書かれたレンタルシステムで実行されているレンタカー会社のレンタルエージェント/マネージャーとして働いています。ちょっとした背景として、このプログラムから毎日対処しなければならない狂気の短い例を以下に示します。 レンタルエージェントは、1つの画面での印刷がACTフィールドで「MXC」を使用することを覚えておく必要があります（すべてが短いコードに基づいています）。これは「MaXimum display on a Contract」を意味し、別の画面ではPR（PRint） ACTIONフィールドですが、いくつかの画面はPT（PrinTの場合）フィールドでYを使用し、さらに別の画面はPRT（PRinTの場合）フィールドでYを使用しますが、さらに別の画面ではユーザーがEnterキーを押す必要があります（ただし、文字、それは改行文字であるため、数字パッドで入力する必要があります）、F8、異なるが関連する画面には単にF8が必要です、一部の画面にはPRinT用のフィールドがありますが、実際にはフィールド何もせず、いくつかのプロンプトを通過した後、印刷が自動的に行われ、さらに多くの画面にPRINT Y / Nというラベルのフィールドがあります。これは、別の場所が既に書類を提出している業務ではデフォルトでYになり、別のディーラーが書類を必要とする業務ではNになります。 私はこれよりも良い仕事をすることができると決めたので、これを更新する決定を下す会社の人に連絡することにしました。最終的に、このプログラムを担当するITのVPに連絡します。私は彼から少し情報を入手し、私のレンタカー会社がIBMメインフレームアセンブラーで書かれたCOBOLを少し混ぜたレンタルプログラムを持っていることを知りました。とにかく彼に私の履歴書をメールしてください（何かが開いた場合）。 これは私の質問につながります。 最初は技術的です。将来、保守性を向上させるという考えで、アセンブリ言語よりも高いレベルの言語で書き直すことを考えています。私の経験分野はC ++なので、それは私にとって明らかな選択です。私は最近、私が話した人がチームが一生懸命働いたと言われているという記事を読んだので、プログラムを更新する簡単な方法を切に必要としています。 -桁のロケーションコード（4ではなく）と8桁の車番号（7ではなく）。更新に関する私の哲学は、このような悲惨な状況であっても、Joelの方針に沿っています：http : //www.joelonsoftware.com/articles/fog0000000069.html要するに、再書き込みは以前のすべてを捨てるのではなく、増分する必要があります新鮮に始めます。 IBMアセンブリをC ++と統合する簡単な方法はありますか？ある場合、どうすればよいですか？私はasmキーワードを漠然と認識していますが、それを使用するのが最適なのか、それとも何か他のことをするのが最適なのかわかりません。そのような計画はお勧めしませんか？私はg ++とGNU makeを使用してLinuxでほとんどの作業を行っているので、それに固有の回答は歓迎されますが、絶対に必要ではありません（どのようなビルドシステムがないのかわからないので、ほとんど何もありません）。 2番目の質問はより政治的です。切り替えを行う必要があることをこの会社に説得するにはどうすればよいですか？理論上のコスト削減は莫大です（私の見積もりによれば、会社はプログラムとやり取りする方法を学ぶためのトレーニングコストの増加だけで年間余分に数百万ドルを無駄にしています）が、私の提案された変更はおそらくすべての現在のプログラマーは、仮に彼らが制定されたとしても仕事を終えているので、変化に対する大きな構造的抵抗があります。 編集：会社が既に持っているものを変更する理由が、私にとって最良の解決策のように思える理由を説明しなければなりません。ただし、これはプログラムの怪物であるため、他の提案を受け入れています。プログラミングの仕事をしたことがないので、間違った分析を修正してください。 まず、既製のソリューションがあります。 この種のことについてのいくつかの中間レベルのマネージャーとの私の話から、新しいシステムに切り替えることの主な懸念の1つは、何十年も会社にいて、今までシステムに慣れている忠実な従業員の大多数です。持っているものを変更できる場合は、現在のインターフェイスを一種の「互換モード」に維持できます。ユーザーは既に現在のシステムを使用するためにログインする必要があるため、ユーザーが（この変更を行った後）初めてログインするときに設定をアクティブ化する機能を追加できます。 「クラシック」インターフェースまたは「新しい」インターフェース。それを可能にする既成のソリューションを見つける方法はありません。 私の会社も私たちが使用するソフトウェアを所有しています。私たちはそれをライセンスしません。これは、私が現在話している経営陣は、実際に私に変更を許可することができる人と同じであることを意味します。サードパーティのソリューションでは、使用する製品を開発した会社から必要な権利を確保することに加えて、会社から承認を得なければならないため、ハードルが追加されます。また、これは会社に「彼らの」製品をあきらめて他の製品を使用するよう説得することを必要とします。これは、私たちが持っているものを更新しようとするよりも大きなハードルのようです。 最後に、将来を見据えて、ユーザーインターフェイスを改善し、いくつかのバグを修正したいだけではありません。これらの「緊急」問題を更新した後、テクノロジーに関連する会社の基本的な方法を更新したいと考えていました。この種の問題に1〜2年費やした後、私の計画は経営陣に戻り、より劇的な変化を提案することでした。会社が運営している多くの方法がありますが、それらは現在使用していない技術によって根本的に改善される可能性があります。たとえば、各リージョンはほぼ同じように動作します。地元の主要空港は、自動車を配送する中心的なハブです。これらは主に必要に応じて送信されます。ただし、空港はすべての操作のホームベースとして使用されます。彼らは1台の車で2人を私の場所に送り、必要のない1台の車を私たちから受け取ります。その後、彼らが入った車と、彼らが取り戻しているもの（空港から32マイル）を持って空港に戻ります。その後、2台の車で5マイル離れた場所に到着し、1台を降ろしてから、もう1台の車で空港に戻ります。たとえ私たちが送り返した車が私たちの近くで必要な同じ種類の車であっても、彼らはこれを行います。私は約2年前から会社に勤めていますが、自動車不足の最も極端な緊急事態（これまで約3回）で、彼らがこれから逸脱しているように見えます。すべての地域で働く4人を、どの車がどこに行くかを決定する自動スケジューリングシステムに置き換え、必要な場所にすべての車を届けるために最短時間+マイル+ドライバーを必要とする経路を見つけようとしますより高いレベルの修正の例は、いつか追加したいと思っています。 ただし、これらすべてを提案することに不安を感じる前に、インターフェイスの更新などの小さなタスクを実行することで、会社とコードベースの足掛かりをつかむことが役立つと思います。アウトソーシングなどのソリューションは、この可能性を排除します。