イースターエッグに対してどんな議論がありますか?イースターエッグをサポートするための議論はありますか?[閉まっている]


28

私は少し道化師なので、イースターエッグのアイデアはまだ私にアピールします。以前にコードにそれらを追加しましたが、私の友人グループは、CTRL-FUを使用して卵をトリガーするという冗談を言っています。

今、私もパフォーマンスについて少し偏執的ですので、可能な限り過剰を取り除くのが好きです。イースターエッグは100%余分なコードであるため、これは大きく矛盾しています。

イースターエッグに対してどのような議論がありますか?また、イースターエッグをサポートするための議論もありますか?


5
私見この質問は、決してやる気のないものではなく、絶対に反対票に値するものではありません。私はこのテーマに非常に興味があります。特に、エンドユーザーである本物のボスがそれをどのように認識しているかを知っています。

これは、古典的な@Mark Trappにとって「私たちはあなたが直面している可能性のある実際の問題を解決するためにここにいます」と言ってもいいでしょう。
Gratzy

1
@ChrisFは、私の質問のProgrammers.stackexchange.com/questions/38810 / ... が「本当の質問」応答を受け取り、これを言ってくれないなら、このサイトの目的に関して本当に混乱しています。
-Gratzy

1
素晴らしい質問、私見。
ウリ

1
@Mark C Aye、私はリソースの無駄遣いについての超偏執狂的です。

回答:


11

いつものように、答えは「依存する」です。

イースターエッグは、プログラム「世界」の調査を促進する1つの方法です。ゲームでは、それはかなり明白です-あなたは最高の山の頂上に登り、それを見つけます(例えば)、しかし他のアプリケーションではイースターエッグとして隠されたオプションを使用しなければなりません。ただし、一部の人々には軽薄と見なされているため、非常に深刻なビジネスアプリケーションを作成している場合は、魔法のキーの組み合わせを見つけたときに歌うハムスター(または何でも)の画面を見せてユーザーを混乱させたくない。

アプリケーションにイースターエッグが含まれていると、パフォーマンスに悪影響を与えることはありません。そのため、アプリケーションの通常の操作でキーボード入力を解析する場合を除き、トリガーとしてCtrl+ FUを使用するのは悪い考えです。コードが見つかった場合にのみ実行される限り、実行時のペナルティはありません。唯一のペナルティは、プログラムサイズの増加です。これは問題になる場合もあれば、そうでない場合もあります。プログラムのサイズに問題がある場合は、絶対に除外してください。

ただし、余分なコードがあるとサポートに問題があります。それでも、コードをサポートし、実行時に問題が発生しないことを確認する必要があります。最後に望むのは、ユーザーがイースターエッグを見つけたときにアプリケーションがクラッシュすることです!


「アプリケーションにイースターエッグを置いても、パフォーマンスに悪影響はありません。実行時にペナルティが発生しないため、実行されます。」本当に?OPの状態としてCTRL-FUによってトリガーされた場合、すべてのキーストロークをトラップしていませんか?
グラッツィー

2
@Gratzy-実際にはそれが良い点です-通常の操作のためにキーストロークをトラップしない限り、それは悪いイースターエッグの例です。
ChrisF

7

開発しているソフトウェアの種類に大きく依存していると思います。

Imhoイースターエッグは、ビジネスソフトウェアよりもゲームで受け入れられる(または高く評価される)可能性が高くなります。マイクロソフトでさえ製品にイースターエッグを入れていましたが、今ではそれをほぼ完全に止めました。マイクロソフトがイースターエッグを入れるのをやめた理由は、イースターエッグに対する考えられる理由:セキュリティ上の懸念と密接に関係しています。関連するウィキペディアの記事で概説されているように、イースターエッグは通常(少なくともユーザー/クライアントにとって)コードの文書化されていない部分であり、製品が攻撃に対してより開かれている、または他の方法で信頼できないと考えるようになります。さらに、すべてのイースターエッグコードが「ミッションクリティカル」コー​​ドと同程度にテストおよび監査されるわけではありません。これにより、コードベースに未発見の欠陥やループホールが発生する可能性があり、それが後の攻撃やマルウェアの悪用の原因になる可能性があります。

ただし、すべてのイースターエッグが「悪い」わけではなく、製品の実際のコードを改ざんする必要があるわけではありません。特に、コードがコンテンツ(ゲーム/グラフィックス/スクリプトエンジン対実際のスクリプトまたはレベルファイル)から分離されているゲームでは、イースターエッグを表示する方法がたくさんあります。これらの方法は、主人公の特別なテクスチャ/オブジェクトおよび音声コメント(たとえば、DN3Dで使用されるDoomTerminatorIndiana JonesStar Trek)から秘密レベル(「牛のレベルはありません」)から特定のオブジェクトユーザーインターフェイスの/ locationをクリックします。もちろん、これらのそれぞれがすべてのタイプの製品に適しているわけではありません。

イースターエッグを製品に入れる良い方法は、自分自身を何らかの形で含めることです(クレジットセクションだけでなく)。BlizzardはこれをStarCraft 2で非常にうまく行いました。1つのユニットのポートレートは、実際には開発者の1人の顔です。それほど明白ではないものは、メディアの知識や特定の種類のユーモアに依存していないため、通常は多くの異なる種類のソフトウェアに適しています。たとえば、製品のコンテキストに自分をキャラクターとして含めることができます。製品によっては、これはコードの機会を必要としない場合もあれば、非常に単純なものだけを必要とする場合もあります。

イースターエッグは私見はいいですが、必須ではありません。イースターエッグの実装は、実際の製品を損なうものであってはならず、そのプレゼンテーションは、最終製品のインデントされたターゲットオーディエンスに適切でなければなりません。「深刻な」アプリケーションのイースターエッグ、または大人以外を対象とした製品には、どんなに面白くても無害に見える大人のユーモアや性的なコンテンツを含めないでください。これは、法的結果につながるだけでなく、ソフトウェアのマーケティング範囲(USK / PEGI / ESRB評価など)にも影響を与える可能性があります。


1
マイクロソフトがコードにイースターエッグを入れるのを止めた理由を本当に見る必要があります。イースターエッグは完全にテストされていないコードパスです(イースターエッグで完全なQAを行う機会があった場合、代わりに別の便利な機能を含めるのに時間をかけなかったのはなぜですか?)セキュリティの脆弱性の潜在的なソース。
アノン。

@アノン:私の答えで述べたウィキペディアの記事から:「過去にMicrosoft Officeのような最大かつ最も精巧なイースターエッグのいくつかを作成したMicrosoftは、一部のソフトウェアとしてイースターエッグを許可しなくなりました。信頼できるコンピューティングイニシアチブ。」その声明の出典は、Charlesの回答にリンクされているMSDNブログ記事です。私の声明に矛盾は見られません。私がどこを間違えたか説明してもらえますか?:)
Baelnorn

答えの最初の部分は「Microsoftがこれを行っていたのはすごいことではありません」のように見えますが、それ以上彼らがそれをしない実際の理由は答えの途中で埋もれています。カジュアルな読者はそれを見ることはなく、関連するコンテキストから切り離されています。理想的には、短所の段落をもう少し目立たせるために、段落の入れ替えをお願いします。
アノン。

@アノン:どうもありがとう。回答を編集し、段落の順序を変更して、最初の部分でEEに対する理由を詳述しました。
-Baelnorn

5

イースターエッグは、80年代および90年代の主要な商用ソフトウェアリリースでも一般的でした。ほとんどの場合、彼らはかわいく、比較的少数の人々が彼らに悩まされました。3つの理由から、今日ではあまり一般的ではないと思います。

  1. すべての実用的なジョークのように、誰かが目を覚ますまで、彼らは面白いです。イースターエッグにデータの損失やパフォーマンスの問題を引き起こすバグがある場合、実際に「マルウェア」を配布していないことを多くの弁護士に説明しなければならない場合があります。

  2. ユーモアは正しいことをするのは非常に難しく、間違ってやると、有料の顧客を怒らせ、その顧客はソフトウェアの支払いをやめ、あなたが働いている何がひどく未熟な会社であるかについて多くの厄介な手紙をマスコミに書きますために。Ctrl-FUによってトリガーされるイースターエッグの例は、完璧な例です。これはおそらく17歳の友人にとってはヒステリックに面白いことですが、冗談でさえも顧客に「FU」を言わないことはマーケティングの0番目のルールです。大きな商用ソフトウェアのイースターエッグは、競合他社だけではなくユーザーをからかわないことに注意してください。

  3. 映画ヘッドのモンキーズのピーター・トークの不滅の言葉で:「誰もユーモアのセンスを持つ人にお金を貸しません。」ソフトウェアインフラストラクチャの重要な部分を購入する場合、作成者のユーモアのセンスは安心できません。それに加えて、多くのセキュリティバグを修正できたのに、なぜイースターエッグを書くのに時間を費やしたのですか?

Larry Ostermanは、MicrosoftのOSグループがイースターエッグを許可しなくなった理由について、数年前にかなり有名なブログ投稿をしました


1
今日でもGoogleが持っているイースターエッグを -彼らの入力のためだチェックが各検索にイースターエッグをトリガすることを意味しています。それはおそらくあまり処理されていませんが、彼らが毎日処理する何億もの検索を考えると...私は知りません。
チャールズサルビア

私はCTRL-FUをKUNG-FUの一種として読んだことを告白しなければなりません。
クリストファー・クロイツィグ

@Christopherそれは完全に合理的な解釈です。ユーモアは多くの場合、複数の解釈の対象となります。これは、誰かを怒らせる危険を冒さずにソフトウェアを組み込むのが難しい理由の一部です。
チャールズE.グラント

@CharlesSalvia検索結果の処理方法に応じて、「どういう意味ですか」という結果を決定しますが、その動作にすでに存在するものの上にオーバーヘッドがまったく追加されない場合があります。
JAB

4

イースターエッグは、ビルダーによって残された小さな秘密です。エンドユーザーを傷つけますか?いや

多くの有名人気のあるソフトウェアには、隠れたイースターエッグが含まています。イースターエッグは、特定の微妙なテーマに関する開発者の気持ちをかなりエレガントな方法で表示するためにも使用されています。

コードの最適化に関しては、イースターエッグがあまり集中的でない限り(hello flight simulator)、意味のある方法でパフォーマンスを損なうべきではありません。


同意しません。イースターエッグは、ユーザーに害を及ぼす可能性のあるイベントが発生するリスクを追加します。せいぜい、これらの「追加された機能」はテストされており、開発者とQAの両方の時間を使い果たしているだけです。最悪の場合、実装者以外は誰もそれについて知りません。実装者は後に会社を退職し、その後ソフトウェアの更新により、キーボードイベントの切断、使用可能なすべてのRAMの消費、極端な場合のユーザーのコンテンツの消去などのアクションで、イースターエッグが意図せずに変身します。ハードドライブ。オーバーザトップ?多分。しかし、これらはそれぞれ通常のバグとして発生します。
ミイラ

@mummey:それは非常にありそうもない出来事だと思います。
ジョシュK

これらのリスクを軽減するために最大限の努力をしませんか?
StuperUser

@Stuper:イースターエッグがプログラムをクラッシュさせたことを聞いたことがありますか?
ジョシュK

聞いたことはありませんが、イースターエッグ中のクラッシュは、大部分の問題の公開を保証するほど重要ではありません。ユーザーは多くの場合、MSプログラムのクラッシュ中に情報を送り返しません。通常、通常の操作場合
StuperUser

2

私はソフトウェアのイースターエッグが好きですが、楽しみのために製品に残された卵と悪意のあるバックドアとの境界線は法的な観点から非常に薄くなる可能性があることを覚えておくことが重要です。たとえば、害を示す必要がありますか?危害を加える意図を証明する必要がありますか?

裁判所がコンピューターとソフトウェアを理解していることは非常に悲惨である(一部のソフトウェア特許で証明されているように)ことを考えると、そのようなケースを議論することで、数人の弁護士がアスペンの素敵な別荘を買うことになります。ソフトウェアが世界中に公開および配布されるさまざまな法的環境(DMCAなど)を考慮すると、アルプスの別荘を購入することもあります。

エンジニアを雇ったので、私たちは会社に害を及ぼさないことを保証します。訴訟が危害になる可能性があります。契約でソフトウェアを他のクライアント、特に政府や大企業に配信する場合、訴訟が発生する可能性があります。したがって、私は個人的に安全面で過ちを犯すことを選択します。

ロジックを悪用するためにエンジニアが存在するのに対し、弁護士は悪のためにロジックをねじるために存在することを忘れないでください。それが彼らが私たちよりもはるかに多く支払われる理由です。


0

イースターエッグはゲームに適していると多くの人が言っていますが、ビジネスアプリケーションで使用できると思います。あまりにも多くの人が、ビジネスアプリケーションを使用するための一連のレシピを作成するだけで、アプリケーションの他の領域を決して見ません。トレーニングの一部でなく、何らかの使用になりかねない場合、彼らは決して見ないアプリケーションのセクションがあります。現在、私は75のレポートを含むアプリケーションに取り組んでおり、ユーザーは情報を求めていて、1つのレポートも実行しませんでした。彼らは好奇心の欠如を補うために何らかのインセンティブを必要としています(防御において、一部のユーザーは何かを壊すことを恐れています)。


-2

イースターエッグを使用して、デバッグとコーディングを支援します。したがって、私が入れたイースターエッグは目的を果たし、おそらくイースターエッグとは見なされません。


「イースターエッグ」とはどういう意味ですか?例を挙げていただけますか?

これはイースターエッグではなく、バックドアです。ツールが画面の場所(0,0)で中マウスボタンをダブルクリックし、正しいパスワードを入力すると、GUIテストのために特別な処理が行われます。これは、GUI自動化ツールが処理できるようにするために行われます。理論的にはユーザーもこれを行うことができますが、実際にはそこに到達しません。さらに、いたるところに警告サインがあります。
ジョブ

1
@Glenn、良い例は...デスクトップGUIアプリケーションを出荷している場合です。ユーザーがボタンをクリックすると、新しいダイアログが表示されます。ユーザーがShiftキーを押しながらそのボタンをクリックすると、古いキーが取得されます。これは、新しいウィジェットによって引き起こされたバグを修正しようとするときに、古い機能と新しい機能を比較する良い方法です。注意が必要な場合は、デュアルコードを残したままバックドアをコメントアウトできます。次に、物事をデバッグする必要がある場合は、コメントを外し、再構築します。2つの物事を並べて比較できます。デイブ、雷を盗もうとしてごめんなさい。
ジョブ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.