プログラムライフの概念をどのように定義できますか？ プログラムの寿命は 、選択したサブジェクト領域のコンテキストで実行されるコンピューターでの有限プロセスの繰り返しシーケンスによって説明できます。 ある程度の妥当な期間で、必然的に有限。
設計
プログラムはいつ表示されますか？ ほとんどの場合、プログラムはデザイナー/開発者の頭に表示され、 デザインタイムと呼ぶことができます。 しかし、この点はコンピューター制御（まだ）に適していないため、プログラムが表示される瞬間が最小の実行可能ファイル（この用語の詳細な意味については別途説明する必要があります）のソースコードであるとします。
モジュラーまたはOOP言語のコンテキストでは、最小限のモジュール/クラスが表示されるときにプログラムが生成されます。 非モジュラー/スクリプティングシステムでは、これらのステージまたはそれらのステージは通常、単一のステージで縮小/スタックされるため、モジュラーシステムについてさらに検討します。
別のカテゴリでデザインタイムを合理的に区別できますが、開発者の頭のプロセスとしてではなく、コーディングプロセスに基づいて純粋に実用的です。 ここでは、オートコンプリート、自動バックライト（既に実装されているプログラムとして）、ideマクロプログラミング、DBスキーマ生成、DRAGONスキーマなどを説明できます。
コンパイルする
次に、いくつかのプログラムコードを記述する段階の後、プログラムはコンパイラに渡されます。 コンパイラは、いわゆる コンパイル時間 - コンパイル時間 。 コンパイルプロセスの結果として、コンパイラが得られます（つまり、ソースコードを処理した直接の結果）。
コンパイル中、ソースコードは、コンパイラコードで表される特定の法律に従ってコンパイラに影響を与えます。
同時に、コンパイラー（より正確にはエグゼキューター全体）の動作を制御するために、プログラムのテキストを書くことによって間接的にではなく、コンパイラーによって実行される汎用コードを直接書くことによって、コンパイル段階で誰も気にしません。
つまり、そのようなコードは、意図したプログラムを参照しますが、コンパイラーによってコンパイラーに直接変換されません。 いわゆるCTFEですが、より一般的な意味です。 コンパイラプロセスのコンテキスト内にあると、 コンパイル時コードにいくつかの制限が課せられる可能性があることは明らかですが、そうではない場合があります。
ここで、ライフサイクル内のプロセスの実装は、明示的または暗黙的に結果の存在を意味することに気付くことができます。
ロード
コンパイラを受け取った後、リンクまたはリンクのプロセスはすぐに、またはその上で延期する必要があります。 コンパイラは通常ファイルに保存されるため、 ロード時間が発生します-load-time 。
この時点で、ターゲットプラットフォームのコードへの追加の変換をコンパイラで実行でき、この時点でロード時間コードを実行できます。たとえば、コンパイラは最適化コンパイラによって処理されます。
現在のところ、WebAssembly（ スリムバイナリ ）というターゲットプラットフォームでのコード生成の遅れが1つだけ知られています。これは、少なくとも何らかの形で読み込み時間を説明しています。
リンク
通常、コンパイラはターゲットマシンで直接実行するために1つのモジュールのコンパイルを常に生成するため、リンクが必要です。 ただし、実際のモジュラーシステムでは、複数のモジュールがマシン上で同時に実行されます。
マルチモジュールシステムのこの状況は、バインディングの必要性につながります。 古いシステムでは、コンパイルの直後にバインディングを実行できますが、この縮退したケースは考慮しません。 そのため、結合時間 、またはリンク時間があります。
リンク中のコード実行についてはほとんど知られていませんが、リンクの瞬間に、依存関係の挿入や動的継承/プロキシなどのコードを実行できることは明らかです。これは、jvm内での作業の一部として実装できるためです。
まだ実行されていないが、すでに実行の準備ができているプログラムコードに対するこのような制御により、自動構成などが可能になります。 リンクと構成が完了すると、コードをすぐに実行できます。
init、実行、閉じる
打ち上げとさらなる作業。 一般に最も知られているステージ。 初期化時間 （ init-time ）およびランタイム （ run-time ）で表されます 。 実際、ライフサイクルのこの段階の結果は、通常、プログラムを作成する直接の目標です。
さらに、プログラムが終了する時間 （ close-time ）を強調表示できます。 ただし、現在は3つの操作時間すべてが通常run-timeと呼ばれ、3段階への論理的な分割はクライアントプログラムコード内で既に実装されています。
このアプローチは、ランタイム環境の要件を軽減しますが、実行エラーが発生すると通常は失敗するため、希望するシーケンスのステージの実行を保証しません。
死
プログラムの人生の別の重要な時間は死の時間であり、これは一般的な信念に反して、プログラムのライフサイクルの一部でもあります。 プログラムの目的は通常結果であり、通常は入力データに非常に依存するため、プログラムは入力データを繰り返し処理し、次の反復の入力に供給できる出力データを生成するメソッドを使用して構築されるため、説明は簡単です。 。
通常、そのようなデータは構造化（DB）、バージョン管理（サードパーティAPIとの相互作用の結果）であり、その内容と解釈は作業プログラムの実装に依存します。 つまり、プログラムは外部のものを含むアルゴリズムとデータであり、これらの外部データとプログラムとの関連性の程度は、ライフサイクルのどの段階でもそのような関連性の存在の事実に影響しません。
簡単に言えば、ライフサイクルの最終段階で取得した結果に応じて、再度起動されたプログラムの動作は異なります。 また、プログラムが実行されていない間にこのデータを変更すると、プログラムの動作も異なります。つまり、データに変更を加えると、プログラムが異なる動作をするようにプログラムされます。 プログラムのライフサイクルのフェーズは何ですか。
まとめ
そのため、プログラムのライフステージは、 設計時 -> コンパイル時 -> ロード時 -> リンク時 -> 初期時間 -> 実行時 -> 終了時 -> 死 時と見なされます。 ご覧のとおり、すべてのステージはプログラムの開発および使用サイクルに存在します。つまり、これらのステージのいずれでもユーザーコードを実行できるため、開発者の目標に最適な結果を得ることができます。 現在まで、これらのステップが完全に実装されるような言語、フレームワーク、またはエコシステムはありません。 科学、ビジネス、そしてコミュニティは努力するべき多くのものを持っています。