私は少し道化師なので、イースターエッグのアイデアはまだ私にアピールします。以前にコードにそれらを追加しましたが、私の友人グループは、CTRL-FUを使用して卵をトリガーするという冗談を言っています。
今、私もパフォーマンスについて少し偏執的ですので、可能な限り過剰を取り除くのが好きです。イースターエッグは100%余分なコードであるため、これは大きく矛盾しています。
イースターエッグに対してどのような議論がありますか?また、イースターエッグをサポートするための議論もありますか?
私は少し道化師なので、イースターエッグのアイデアはまだ私にアピールします。以前にコードにそれらを追加しましたが、私の友人グループは、CTRL-FUを使用して卵をトリガーするという冗談を言っています。
今、私もパフォーマンスについて少し偏執的ですので、可能な限り過剰を取り除くのが好きです。イースターエッグは100%余分なコードであるため、これは大きく矛盾しています。
イースターエッグに対してどのような議論がありますか?また、イースターエッグをサポートするための議論もありますか?
回答:
いつものように、答えは「依存する」です。
イースターエッグは、プログラム「世界」の調査を促進する1つの方法です。ゲームでは、それはかなり明白です-あなたは最高の山の頂上に登り、それを見つけます(例えば)、しかし他のアプリケーションではイースターエッグとして隠されたオプションを使用しなければなりません。ただし、一部の人々には軽薄と見なされているため、非常に深刻なビジネスアプリケーションを作成している場合は、魔法のキーの組み合わせを見つけたときに歌うハムスター(または何でも)の画面を見せてユーザーを混乱させたくない。
アプリケーションにイースターエッグが含まれていると、パフォーマンスに悪影響を与えることはありません。そのため、アプリケーションの通常の操作でキーボード入力を解析する場合を除き、トリガーとしてCtrl+ FUを使用するのは悪い考えです。コードが見つかった場合にのみ実行される限り、実行時のペナルティはありません。唯一のペナルティは、プログラムサイズの増加です。これは問題になる場合もあれば、そうでない場合もあります。プログラムのサイズに問題がある場合は、絶対に除外してください。
ただし、余分なコードがあるとサポートに問題があります。それでも、コードをサポートし、実行時に問題が発生しないことを確認する必要があります。最後に望むのは、ユーザーがイースターエッグを見つけたときにアプリケーションがクラッシュすることです!
開発しているソフトウェアの種類に大きく依存していると思います。
Imhoイースターエッグは、ビジネスソフトウェアよりもゲームで受け入れられる(または高く評価される)可能性が高くなります。マイクロソフトでさえ製品にイースターエッグを入れていましたが、今ではそれをほぼ完全に止めました。マイクロソフトがイースターエッグを入れるのをやめた理由は、イースターエッグに対する考えられる理由:セキュリティ上の懸念と密接に関係しています。関連するウィキペディアの記事で概説されているように、イースターエッグは通常(少なくともユーザー/クライアントにとって)コードの文書化されていない部分であり、製品が攻撃に対してより開かれている、または他の方法で信頼できないと考えるようになります。さらに、すべてのイースターエッグコードが「ミッションクリティカル」コードと同程度にテストおよび監査されるわけではありません。これにより、コードベースに未発見の欠陥やループホールが発生する可能性があり、それが後の攻撃やマルウェアの悪用の原因になる可能性があります。
ただし、すべてのイースターエッグが「悪い」わけではなく、製品の実際のコードを改ざんする必要があるわけではありません。特に、コードがコンテンツ(ゲーム/グラフィックス/スクリプトエンジン対実際のスクリプトまたはレベルファイル)から分離されているゲームでは、イースターエッグを表示する方法がたくさんあります。これらの方法は、主人公の特別なテクスチャ/オブジェクトおよび音声コメント(たとえば、DN3Dで使用されるDoom、Terminator、Indiana Jones、Star Trek)から秘密レベル(「牛のレベルはありません」)から特定のオブジェクトユーザーインターフェイスの/ locationをクリックします。もちろん、これらのそれぞれがすべてのタイプの製品に適しているわけではありません。
イースターエッグを製品に入れる良い方法は、自分自身を何らかの形で含めることです(クレジットセクションだけでなく)。BlizzardはこれをStarCraft 2で非常にうまく行いました。1つのユニットのポートレートは、実際には開発者の1人の顔です。それほど明白ではないものは、メディアの知識や特定の種類のユーモアに依存していないため、通常は多くの異なる種類のソフトウェアに適しています。たとえば、製品のコンテキストに自分をキャラクターとして含めることができます。製品によっては、これはコードの機会を必要としない場合もあれば、非常に単純なものだけを必要とする場合もあります。
イースターエッグは私見はいいですが、必須ではありません。イースターエッグの実装は、実際の製品を損なうものであってはならず、そのプレゼンテーションは、最終製品のインデントされたターゲットオーディエンスに適切でなければなりません。「深刻な」アプリケーションのイースターエッグ、または大人以外を対象とした製品には、どんなに面白くても無害に見える大人のユーモアや性的なコンテンツを含めないでください。これは、法的結果につながるだけでなく、ソフトウェアのマーケティング範囲(USK / PEGI / ESRB評価など)にも影響を与える可能性があります。
イースターエッグは、80年代および90年代の主要な商用ソフトウェアリリースでも一般的でした。ほとんどの場合、彼らはかわいく、比較的少数の人々が彼らに悩まされました。3つの理由から、今日ではあまり一般的ではないと思います。
すべての実用的なジョークのように、誰かが目を覚ますまで、彼らは面白いです。イースターエッグにデータの損失やパフォーマンスの問題を引き起こすバグがある場合、実際に「マルウェア」を配布していないことを多くの弁護士に説明しなければならない場合があります。
ユーモアは正しいことをするのは非常に難しく、間違ってやると、有料の顧客を怒らせ、その顧客はソフトウェアの支払いをやめ、あなたが働いている何がひどく未熟な会社であるかについて多くの厄介な手紙をマスコミに書きますために。Ctrl-FUによってトリガーされるイースターエッグの例は、完璧な例です。これはおそらく17歳の友人にとってはヒステリックに面白いことですが、冗談でさえも顧客に「FU」を言わないことはマーケティングの0番目のルールです。大きな商用ソフトウェアのイースターエッグは、競合他社だけではなくユーザーをからかわないことに注意してください。
映画ヘッドのモンキーズのピーター・トークの不滅の言葉で:「誰もユーモアのセンスを持つ人にお金を貸しません。」ソフトウェアインフラストラクチャの重要な部分を購入する場合、作成者のユーモアのセンスは安心できません。それに加えて、多くのセキュリティバグを修正できたのに、なぜイースターエッグを書くのに時間を費やしたのですか?
Larry Ostermanは、MicrosoftのOSグループがイースターエッグを許可しなくなった理由について、数年前にかなり有名なブログ投稿をしました。
イースターエッグは、ビルダーによって残された小さな秘密です。エンドユーザーを傷つけますか?いや
多くの有名で人気のあるソフトウェアには、隠れたイースターエッグが含まれています。イースターエッグは、特定の微妙なテーマに関する開発者の気持ちをかなりエレガントな方法で表示するためにも使用されています。
コードの最適化に関しては、イースターエッグがあまり集中的でない限り(hello flight simulator)、意味のある方法でパフォーマンスを損なうべきではありません。
私はソフトウェアのイースターエッグが好きですが、楽しみのために製品に残された卵と悪意のあるバックドアとの境界線は法的な観点から非常に薄くなる可能性があることを覚えておくことが重要です。たとえば、害を示す必要がありますか?危害を加える意図を証明する必要がありますか?
裁判所がコンピューターとソフトウェアを理解していることは非常に悲惨である(一部のソフトウェア特許で証明されているように)ことを考えると、そのようなケースを議論することで、数人の弁護士がアスペンの素敵な別荘を買うことになります。ソフトウェアが世界中に公開および配布されるさまざまな法的環境(DMCAなど)を考慮すると、アルプスの別荘を購入することもあります。
エンジニアを雇ったので、私たちは会社に害を及ぼさないことを保証します。訴訟が危害になる可能性があります。契約でソフトウェアを他のクライアント、特に政府や大企業に配信する場合、訴訟が発生する可能性があります。したがって、私は個人的に安全面で過ちを犯すことを選択します。
ロジックを悪用するためにエンジニアが存在するのに対し、弁護士は悪のためにロジックをねじるために存在することを忘れないでください。それが彼らが私たちよりもはるかに多く支払われる理由です。
イースターエッグはゲームに適していると多くの人が言っていますが、ビジネスアプリケーションで使用できると思います。あまりにも多くの人が、ビジネスアプリケーションを使用するための一連のレシピを作成するだけで、アプリケーションの他の領域を決して見ません。トレーニングの一部でなく、何らかの使用になりかねない場合、彼らは決して見ないアプリケーションのセクションがあります。現在、私は75のレポートを含むアプリケーションに取り組んでおり、ユーザーは情報を求めていて、1つのレポートも実行しませんでした。彼らは好奇心の欠如を補うために何らかのインセンティブを必要としています(防御において、一部のユーザーは何かを壊すことを恐れています)。
イースターエッグを使用して、デバッグとコーディングを支援します。したがって、私が入れたイースターエッグは目的を果たし、おそらくイースターエッグとは見なされません。