まだ作成されていないアプリケーションへの将来の影響を最小限に抑えることを検討しています。サードパーティ製品を避けようとしており、オペレーティング システム固有の呼び出しも避けようとしています。アプリケーションを将来的に証明する他の方法を提案できる人はいますか? アイデアは、10 年または 20 年で大部分を書き直す必要がなく、メンテナンス (バグ修正) だけを行う必要があるということです。
6 に答える
6
プログラムをそのような期間（最新のOSで）実行し続けたい場合は、おそらく純粋なANSI C（またはC ++）でのみプログラムを作成する必要があります。それ以外の場合は、何年にもわたって何らかの調整が必要になる可能性があります。今後10〜20年で何が起こるかは誰にもわかりません。
そうは言っても、これらの種類の問題を最小限に抑えるためのヒントをいくつか紹介します。
- 奇妙な依存関係を避けてください。いくつかのライブラリに依存する場合は、それが非常に確立されている（したがって、10〜20年のうち少なくとも5年は存続する可能性が高い）か、少なくともオープンソースであることを確認してください。必要に応じて自分でフォークできます。なれ。
- OS固有の呼び出しは避けてください。これは、1とのバランスを取る行為になります。- boost、Qt、glib、what-have-youなどのラッパーライブラリを使用できますが、互換性の問題が発生する可能性が高くなります。
- すべてを文書化します。事実は、どんなに頑張っても、このプログラムには互換性の修正とバグの修正が必要であり、おそらく機能の追加も必要です。ですから、15年後にやってくる貧しいメンテナンスプログラマーの生活を楽にしてください。:)
于 2009-05-05T06:50:04.290 に答える
2
今日のマシンでまだ実行されている 10 年前と 20 年前のプログラムをいくつか掘り出し、それらがまだ実行されている理由と価値がある理由を確認してください。多くの計算集約型のコンソール ベースのアプリがまだ時折使用されているのを目にしますが、そのほとんどは C と FORTRAN で記述され、他のアプリから呼び出されます。アプリに多くの GUI が含まれている場合、数十年後も価値があると確信していますか? おそらく、UI パラダイムの変化と進化に合わせて将来的に UI を置き換えることができるように、コア機能からユーザー インターフェイスを分離することを検討してください。非常にモジュール化された方法でシステムを作成すると、まだ価値のあるモジュールを保持し、明らかに時代遅れになっているモジュールを置き換えることができます。
于 2009-05-05T07:22:09.173 に答える
1
64ビットを念頭に置いて記述してください。現在、サードパーティの依存関係の多くが64ビットをサポートしていないことがわかりました。そのため、問題が発生しています。
于 2009-05-05T07:11:21.010 に答える
1
10 年後もメンテナンスをほとんどまたはまったく必要とせずに機能するアプリケーションを構築する最善の方法は、10 年前に構築され、現在も稼働しているシステムを調べることです。
私の経験から言うと、メジャー アップグレードを必要としないこれらのシステムのほとんどは、10 年前に展開されたものと同じまたは類似のハードウェア上で実行され、同じインターフェイスを使用することによってアップグレードを行っています。
保守担当者は、ムーアの法則によるパフォーマンスの向上または使いやすさの向上をトレードオフして、何年にもわたってメンテナンスをほとんどまたはまったく行わないことを選択しました。
于 2009-05-05T07:33:23.733 に答える
0
私が開発する多くのアプリケーションは、周期的に実行されます (例: 毎年)。それらが確実に機能し続けるために最も重要なことは、日付や日付範囲をハードコーディングしないことです。例：
year(now())一年間DateSubmitted BETWEEN year(now()) AND DATEADD(year,1,year(now()))範囲の
もちろん、これらはほんの一例です。
于 2009-05-05T16:57:15.033 に答える
0
テストの自動化も役立ちます。アプリケーションが「証明」されるわけではありませんが、状況が変わったときに何を修正する必要があるかについては、ある程度理解できるでしょう。
于 2009-05-05T07:25:14.580 に答える