質問: c ++でのibmアセンブラ+ cobolの書き換え 私は1972年に作成されたレンタルシステムで実行されているレンタカー会社のレンタルエージェント/マネージャーとして働いています。更新の時期だと思いました。背景について少し説明しますが、これは毎日このプログラムで対処しなければならない狂気の短い例です。レンタルエージェントは、1つの画面での印刷でactフィールドに「mxc」が使用されることを覚えておく必要があります(すべてが短いコードに基づいています)。これは当惑して「契約のmaximum表示」を表し、別の画面ではpr(printの場合)が必要です。 actionフィールドですが、いくつかの画面ではpt(printの)フィールドでyを使用していますが、別の画面ではprt(printの)フィールドでyを使用していますが、別の画面ではユーザーがenterキーを押す必要があります(ただし、文字、それは改行文字なので、それはテンキーのenterキーである必要があります)、次にf8、異なるが関連する画面は単にf8を必要とし、一部の画面にはprtというラベルの付いたフィールドがあります。何もせず、いくつかのプロンプトを通過した後、印刷は自動的に行われ、さらに多くの画面にprint y/nというラベルの付いたフィールドがあります。ディーラーは事務処理が必要になります。私はこれよりも良い仕事をすることができると決めたので、これを更新することを決定する会社の担当者に連絡することにしました。最終的には、このプログラムを担当するit担当副社長に連絡します。私は彼から少し情報を得て、私のレンタカー会社がibmのメインフレームアセンブラーでレンタルプログラムを書いていて、少しのcobolが混在していることを知りました。彼は現在空いているポジションはありませんが、とにかく彼に私の履歴書をメールで送ってください(何かが開かれた場合に備えて)。これは私の質問につながります。最初は技術的です。将来の保守性を向上させるという考えから、アセンブリ言語よりも高水準の言語で書き直すことを考えています。私の経験分野はc++なので、それは私にとって明らかな選択です。私が最近話し合った男性がチームが懸命に働いたと言っていると述べられている記事を最近読んだので、会社はプログラムを更新する簡単な方法を切実に必要としており、彼らはプログラムが5をサポートしていることを発表できて誇りに思っています桁のロケーションコード(4の代わりに)および8桁の車の番号(7の代わりに)。更新に関する私の哲学は、この悲惨な状況でも、joelの方針に沿っています: http://www.joelonsoftware.com/articles/fog0000000069.html つまり、書き換えは増分的である必要があります。以前あったすべてのものを捨てて、新鮮に始めるより。ibm assemblyをc++と統合する簡単な方法はありますか?その場合、どのようにすればよいですか?私は漠然とasmキーワードを認識していますが、それを使用するのが最適なのか、それとも他のことをするのが最善なのかわかりません。そのような計画は不適切です。私はg ++とgnu makeを使用してlinuxでほとんどの作業を行っているので、それに固有の回答は歓迎されますが、絶対に必要ではありません(どのようなビルドシステムがないかわからないため、しかし、私はほとんど何も疑っていません)。2番目の質問はより政治的です。この会社を説得して、切り替えを必要とするようにするにはどうすればよいですか?理論的なコスト削減は莫大です(私の見積もりに基づいて、会社はプログラムと対話する方法を学ぶためのトレーニングコストの増加だけで、年間100万ドル以上の無駄遣いをしています)が、提案された変更はおそらくすべての現行のプログラマーは、彼らが制定された場合、失業するため、変化に対する大きな構造的抵抗があります。編集:私が会社がすでに持っているものを変更することが私にとって最高の解決策のように思われる理由を説明する必要があります。ただし、これはプログラムの怪物なので、私は他の提案を受け入れています。今までプログラミングの仕事をしたことがないので、間違った分析があれば修正してください。まず、既成のソリューションがあります。この種のことについての中間管理職数人との話し合いから、新しいシステムへの切り替えに関する主な懸念の1つは、何十年も会社にいて、現在システムに慣れている多くの忠実な従業員です。 。自分が持っているものを変更する能力があれば、現在のインターフェースを一種の「互換モード」に維持できます。ユーザーは既に現在のシステムを使用するためにログインする必要があるため、ユーザーが(この変更を行った後)初めてログインしたときに設定をアクティブにする機能を追加できます。 「クラシック」インターフェースまたは「新しい」インターフェース。それを可能にする既成の解決策を見つける方法はありません。テクノロジーの変更によって上級社員が混乱するのではないかという恐れが、上級管理職がノーと言う主な理由だと思います。私の会社も私たちが使用するソフトウェアを所有しています。ライセンスはありません。これは、私が現在話している経営陣が、実際に私に変更を加えることを許可できる人と同じであることを意味します。サードパーティのソリューションを使用する場合、使用する製品を開発した会社から必要なすべての権利を確保することに加えて、会社の承認を得る必要があり、さらにハードルが追加されます。これはまた、会社に「彼らの」製品をあきらめて他の製品を採用するよう説得することを必要とします。これは私たちが持っているものを更新しようとするよりも大きなハードルのようですが、私はこの問題について非常に間違っている可能性があります。最後に、将来を見据えて、ユーザーインターフェイスを改善し、いくつかのバグを修正するだけではありません。これらの「緊急」の問題を更新した後、テクノロジーに関連する会社の基本的な運営方法を更新したいと思っていました。このような問題に1〜2年費やした後、私の計画は経営に戻り、より劇的な変化を提案することでした。現在使用されていないテクノロジーによって根本的に改善できる可能性のある会社の運営方法は数多くあります。たとえば、各リージョンはほとんど同じように動作します。地方の主要空港は、自動車を販売するための中心的なハブです。それらは主に必要に応じて送信されます。ただし、空港はすべての操作の拠点として使用されます。彼らは1台の車で2人の人を私の場所に送り、私たちから不要な1台の車をピックアップし、彼らが来た車と彼らが持っているもの(空港から32マイル)を空港に返します空港)。それから、彼らは私たちから5マイル離れた場所に2台の車で来て、1台を降ろしてから、他の車で空港に戻ります。私たちが返送した車が私たちの近くに必要な同じ種類の車であっても、彼らはこれを行います。私はこの会社に2年ほど在籍しており、自動車不足の最も極端な緊急事態(これまでに約3回)でのみ、これから逸脱しているように見えます。すべての地域で働く4人を自動化されたスケジューリングシステムに置き換え、どの車がどこに行くかを決定し、必要なすべての車を提供するために最短の時間+マイル+ドライバーが必要な経路を見つけて、より高いレベルの修正の例をいつか追加したいと思っています。ただし、これをすべて提案する前に、インターフェイスの更新など、より小さなタスクを実行することで、会社とコードベースを理解しておくと役に立ちます。アウトソーシングなどのソリューションは、この可能性を排除します。
回答: 段階的な変更は問題外です。 市販のソリューションが利用できる可能性があります。多くのレンタカー会社があります。 最後の手段としてそれを書き直す必要がある場合は、まず新しいシステムがどのように機能するかを考えるのに少し時間を費やしてください。 機能とインターフェイスを特定したら、ニーズ(およびスキル)に最適な開発ツールを選択できます。 エンドユーザーへのストレスを最小限に抑える方法の1つは、醜いニーモニックのドロップダウンリストなどのいくつかの優れた機能を備えた、ユーザーが知っている古い醜いインターフェイスのエミュレーションを開始し、ui機能を徐々に追加して、モダンなuiにそれらを追加することです。おそらく同じデータファイル形式を維持したくないので、切り替え後は元に戻せません。