しばらくの間プログラミングをしているほとんどの人がそうであるように、私は「プロダクション コード」という用語に精通しており、それが何を意味するのか漠然とした感覚を持っています。しかし、Wikipedia と Google はできないように見えるので、誰かがやや厳密な定義を提供できますか? 少数の人々によって使用されているため、UI、ドキュメントなどの点で「形式化」されていない内部ツールや、機能は完全で、適度にバグがなく、機能していますが、洗練された UI と広範なテストが欠けています。
12594 次
9 に答える
25
コードが本番システムで実行されるということは、実際の状況で対象ユーザーによってコードが使用されていることを意味します。
ただし、製品コードは、必ずしも堅牢で信頼性が高く、安定したコードを意味するわけではありません。 Daily WTFは、この点に関して多くの証拠を提供しています。
于 2009-01-29T02:33:42.540 に答える
20
生産とは、確実に一貫して作業するために必要なものすべてを意味します。
ビルド スクリプトであるか、公開されている Web サーバーであるか。
他の人があなたのコードに依存している場合、特にそれを理解していない可能性がある人 (つまり、「頭の良い」開発者でも、おそらくあなたのグループには属していないが、あなたが作成したライブラリを使用している) は、そのコードは製品コードです。
本番コードが失敗すると「作業が止まる」「お金がなくなる」ので本番です。
于 2009-01-29T02:26:33.863 に答える
8
私が理解している定義では、本番コードは、ライブの非テストベッド システムにインストールまたは使用されているコードです。会社の内部で使用されるサーバーは、会社の従業員が使用するライブ システムである場合、運用システムです。ここでのポイントは、コードを書いている会社の内部サーバーで実行されているコードは、製品コードになる可能性があるということです。
通常、内部コードを見るときの適切な区別は、コードを維持しているグループがコードを使用しているグループから分離されているかどうかです。グループが分かれている場合、そのコードは製品コードである可能性があります。ビジネスの運営がコードに依存している場合、社内で開発および保守されている場合でも、それは確かに製品コードです。
于 2009-01-29T02:25:57.203 に答える
3
編集: 短い答え: 「ファームに賭ける」場合、それは「生産」です。
これは素晴らしい質問です。誤解が原因で誰もが日常的にトラブルに巻き込まれる絶対的に重要な違いです。「生産」とは何かという問題は、「環境」とは何かという関連する問題のサブセットです。
したがって、答えの一部は、「生産」が最も重要であり、「 本物の」ものとして最も信頼されている「環境」であるということです。
そのため、「環境」を定義する必要があります(そして、「プロダクション」を再検討します)。 私たちはまだ満足のいく答えには程遠い.
私たちプログラマーは、ソフトウェアを実行するハードウェアで構成されるコンピューター システムを表すために、「環境」という用語を常に使用しています。そのソフトウェアとは、私たちが書いたコードと、それが依存するソフトウェアであり、他の人が書いたものです。私たちはコードを書き、それを他のソフトウェアと統合します。次に、最終的に実行するまで、一連のテスト (単体テスト、統合テスト、機能テスト、受け入れテスト、回帰テストなど) をエスカレートしながら、統合されたソフトウェアを実行します。意図された完全な方法で統合されたソフトウェア。
もちろん、すべてが完全に自動化されているわけではありません。通常は多数の人が関与し、実行する手作業のプロセスがあります。私たちプログラマーは、これらのプロセスを可能な限り自動化する方法を模索していますが、私たちが取り組んでいるシステムには常に「人と機械の境界」があります。多くの場合、特定のケースではそのような境界が多数存在します。
一方、重要な自動化はまったくない場合があります。たとえば、製品を生産する肉体労働を行う人々で部屋がいっぱいだったとき、私たちは「生産」について話しました。したがって、「本番環境」に自動化が存在する必要はありません。布を織るために織機を動かしている人の場合のように、関連する自動化にソフトウェアが含まれていない場合もあります。
また、製品のないサービス プロバイダーを含むように「運用」「環境」という言葉を適応させているため、製品がない場合もあります。
同様に、ソフトウェア駆動型でない機械 (織機など) や人 (トレーニングと評価) をテストする場合もあるため、テストにソフトウェアが含まれない場合もあります。
これで、「環境」のすべての重要な要素に触れました。
- 目的があり
intent、追求されている - an
intentには意図が必要ですsponsor。intent intentさまざまな方法processesで実行されるactors- それら
actorsは人間である可能性があり、ハードウェア上で実行されるソフトウェアである可能性があるか、またはソフトウェア駆動型でないマシンである可能性があるため、自動化が存在する場合と存在しない場合があります。
これで、元の用語を適切かつ完全に定義できます。
は、その に代わって特定のものを追求するために協力する
environmentすべてのprocessesとそのメンバーで構成されます。つまり、ハードウェア上で実行されるソフトウェア、非ソフトウェア駆動型のマシン、そして人々がさまざまな任務を遂行することを意味します。主に を定義するのはであり、そのやそのではありません。actorsintentsponsorintentenvironmentprocessesactors
さらに...
特定の
intentものを追求することenvironmentがsponsor's最終的な目標である場合、通常はお金と引き換えに を生産productまたは提供することを含み、それをと呼びます。serviceenvironmentproduction
これで、もう少し先に進むことができます。
intentで追求されているのenvironmentが の検証でprocessesあり、そのactors準備である場合production、それを と呼びます。testenvironmentさらに、そのテストには、重要な個人またはグループとそのグループの最初の結合が含まれているかどうかと呼びます。
integrationenvironmentprocessesactorsその準備が
actorsnew を実行するため の人間の「プログラミング」processes、またはその後の検証 (評価) を含む場合、それを と呼びます 。trainingenvironment
これらの区別と定義により、いくつかの一般的なシナリオを理解できるようになりました。
環境が として使用されている場合など、 はenvironmentその と一致しない名前で誤ってラベル付けされる可能性があります。intenttrainingtest
やが で行わenvironmentれる場合など、 はひどく誤用される可能性があります。integrationtrainingproduction
キーまたはが識別されないままになっている場合など (例: 手動での調整、または人々を完全に無視することによって) は、environment誤って伝えられる可能性があります。processesactors
とを新しい にenvironment転用することで、 を再タスクできます。一部の組織にとって非常に成功している手法は、リリースごとに、、の間で(ソフトウェアをホストするサーバー) のセットを定期的に「入れ替える」ことです。processesactorsintentactorsproductiontesttrainingintegration
ほとんどの場合、1actor人 (人またはハードウェア) が複数processesを実行でき、複数の に参加できますenvironments。たとえば、単一のコンピュータ サーバーは、トランザクションを実行するソフトウェアをホストしながら、実行または機能productionする他のソフトウェアもホストできます。testtraining
通常、 の 1 つのインスタンスは、一度にactor1 つのみenvironmentに参加する必要があります。相互に互換性がある場合、ごくまれに、単一のactorデバイスを共有できます。ほとんどの場合、実際には互換性がないため、このような共有を試みることは非常に賢明ではありません。完璧な例は、 もサポートするサーバーで を実行している場合です。これにより、サーバー全体に障害が発生するため、ダウンタイムが発生します。environmentsintentsintentstest processproduction processestest
したがって、 のは、可用性、信頼性、パフォーマンス、災害復旧、正確性、精度、再現性、寿命などの概念を含む、非常に広い自由度で解釈intentする必要があります。電力、冷却、バックアップ、および冗長性を提供します。environmentactorsprocesses
最後に、状況が非常に複雑になる可能性があることに注意してください。たとえば、デスクトップ コンピューター ( actor) は、開発チーム ( ) によってsponsorソース コントロール ( ) をホストするように割り当てられprocess、チームは主要な仕事 ( ) のためにソース コントロールに依存する場合がありproductionます。それにもかかわらず、IT スタッフは、同じデスクトップ コンピュータを単なる開発者用ワークステーション (developmentではなくproduction) と見なし、ハードウェアの問題が発生したときに軽蔑して無頓着に扱います。しかし、開発者はproductionコードを作成しているので、開発者も の一部ではありませんproductionか? 視点が重要です。
編集：生産品質
確固たる検証 ( testing) 方法論では、パッケージ化されたコードを取得developmentし、一連のtests(統合、TQA、機能、回帰、受け入れなど) を実行して、反対側で使用するために「スタンプ」を付ける必要がありproductionます。ただし、それはパッケージの品質を高めますが、実際にはそうではありません。パッケージは、がその最終レベルの に実際に展開したときにのみなります。production productionproductionsponsorenvironmentintent
ただし、組織が単にそのパッケージ (そのproduct) を他のユーザーが使用するために作成するだけの場合、そのようなリリースは、productionその組織が経験するものとほぼ同じになるproductため、適用する用語productionを明確にするのではなく、適用するのが一般的です。それは品質です。実際には、その組織の環境は で構成されており、その開発/リリース作業に関与しており、結果として.production productionactorsprocessesproduct
私はそれがかなり複雑になる可能性があると言いました...
于 2009-01-29T06:22:05.777 に答える
1
- 本番ソフトウェアは、サービスを中断または低下させることなく、必要なワークロードで実行できます
- ソフトウェアは、さまざまな実稼働シナリオで正常にテストされています
- 作業中のプロトタイプを、実際のビジネス、つまり本番環境で機能するフェイルセーフ冗長アーキテクチャで実行される本番ソフトウェアに変換するには、時間、コードのリファクタリング、および細部への注意が必要です。
- 製品コードの保守性は許容レベルであり、十分にコメントされています。
- ドキュメンテーションマニュアルは、機能、すべての機能を説明し、メンテナンスを容易にします
- 本番ソフトウェアが国際的なサービスまたはアプリケーションである場合は、ローカライズする必要があります
- 製品コードはエンドユーザー (多くの場合、利用規約に記載されている条件の下で顧客) によって使用されます。
- 本番ソフトウェアは、必ずしも信頼できるミッション クリティカルなソフトウェアを意味するわけではありません
- ソフトウェアは、それが意図したことをうまく実行します
- ログ ファイルは、実行時のパフォーマンスとソフトウェアの信頼性の指標とレポートの正確な説明を提供し、デバッグとソフトウェアの保守性を容易にします。
于 2014-12-30T22:12:27.413 に答える
1
意図したユーザーベースで使用されるコードは、私の「プロダクション コード」の定義に適合します。
もちろん、その定義の灰色の領域は、ユーザーベースが誰であるかを明確に定義することになります.
Gマン
于 2009-01-29T03:26:01.203 に答える
0
簡単に言えば、「実際に使用され、意図された対象者によって使用されている製品コード」
于 2009-01-29T07:20:59.090 に答える
-1
「プロダクション コード」という用語には、2 つの異なる概念が混在しています。1 つは展開管理で、もう 1 つはリリース ライフ サイクルです。
厳密な意味では、システムがビジネスまたはサービス運用の一部として使用されている場合、システムは運用中です。本番環境にないのは、開発、テスト、QA、デモ、およびステージング システムです。生産システムはすぐに品質を意味するものではありません。
リリース ライフ サイクルの観点から見ると、「プロダクション」ビルドは、一般向けまたはクライアント向けにリリースされるビルドです。プレアルファ、アルファ、ベータ（機能完成、コード完成など）、リリース候補の次の段階です。アップデートを簡単に展開できないシュリンク ラップ製品の場合、生産段階に到達することは、一連のテストとバグ修正を意味する可能性があります。
于 2009-01-29T07:17:14.120 に答える