부활절 달걀에 대해 어떤 주장이 있습니까? 부활절 달걀을지지하는 주장이 있습니까? [닫은]

28

나는 약간의 광대 한 사람이므로 부활절 달걀에 대한 아이디어는 여전히 나에게 호소력이 있습니다. 나는 전에 내 코드에 추가했지만 내 친구 그룹은 CTRL-FU를 사용하여 계란을 트리거하는 농담을하고 있습니다.

이제 성능에 대해서도 약간의 편집증이 있으므로 가능할 때마다 초과 량을 제거하는 것이 좋습니다. 이것은 100 % 불필요한 코드이기 때문에 부활절 달걀과 크게 모순됩니다.

부활절 달걀에 대해 어떤 주장이 있습니까? 또한 부활절 달걀을지지하는 주장이 있습니까?

efficiency easter-eggs

5

이호는이 질문에 전혀 투표권이 없다. 확실히 동기 부여가 아닌 것은 아니다. 나는 그 주제에 관심이 많다. 특히 최종 사용자, 실제 보스가 어떻게 인식하는지 알고 있습니다.

이것은 고전적인 @Mark Trapp의 핵심입니다. "현재 직면하고있는 실제 문제를 해결하기 위해 여기에 있습니다."

— Gratzy

1

@ChrisF 와우 내 질문 programmers.stackexchange.com/questions/38810/… "실제 질문"응답을 얻었을 때 이것이 그렇지 않다고 말하면 이 사이트의 목적에 대해 정말 혼란 스럽습니다.

— Gratzy

1

좋은 질문입니다. IMHO.

— Uri

1

@Mark C Aye, 나는 자원 낭비에 대한 최고의 편집증입니다.

11

언제나 그렇듯이 대답은 "의존"입니다.

부활절 달걀은 "세계"프로그램의 탐색을 장려하는 한 가지 방법입니다. 게임에서 그것은 분명합니다-당신은 가장 높은 산 꼭대기로 올라가서 그것을 발견합니다 (예를 들어). 그러나 다른 응용 프로그램에서는 숨겨진 옵션을 이스터 에그로 사용해야합니다. 그러나 일부 사람들에게는 경솔한 것으로 보이므로 매우 심각한 비즈니스 응용 프로그램을 작성하는 경우 마법의 키 조합을 찾을 때 노래 햄스터 (또는 그 밖의 것) 화면을 제시하여 사용자를 화나게하고 싶지 않습니다. .

응용 프로그램에 이스터 에그가 있어도 성능에 해로운 영향을 미치지 않아야합니다. 따라서 트리거로 Ctrl+ FU를 갖는 응용 프로그램의 정상적인 작동을 위해 키보드 입력을 구문 분석하지 않는 한 나쁜 생각입니다. 코드가 발견 된 경우에만 실행되므로 런타임 패널티는 없습니다. 유일한 벌칙은 프로그램 크기의 증가입니다-문제가 될 수도 있고 아닐 수도 있습니다. 프로그램 크기가 문제라면 반드시 빼십시오.

그러나 추가 코드가 있으면 지원 문제가 있습니다. 여전히 코드를 지원하고 코드가 작동하고 실행될 때 문제를 일으키지 않는지 확인해야합니다. 마지막으로 원하는 것은 사용자가 이스터 에그를 찾듯이 응용 프로그램이 중단되는 것입니다!

— 크리스프
소스

"응용 프로그램에 이스터 에그가 있어도 성능에 해로운 영향을 미치지 않아야합니다. 발견 된 경우에만 실행되므로 런타임 패널티가 없습니다." 정말? OP 상태로 CTRL-FU에 의해 트리거되면 모든 키 스트로크를 트래핑하지 않습니까?

— Gratzy

2

@Gratzy-사실 그것은 좋은 지적입니다-정상적인 작동을 위해 키 입력을 포착하지 않으면 부활절 달걀의 예입니다.

— ChrisF

7

개발중인 소프트웨어 유형에 따라 크게 달라집니다.

Imho 부활절 달걀은 비즈니스 소프트웨어보다 게임에서 더 잘 받아 들여질 가능성이 높습니다. 심지어 마이크로 소프트조차도 이스터 에그 (Easter Eggs)를 제품에 넣었지만 지금은 거의 완전히 중단했습니다. Microsoft가 Easter Eggs 도입을 중단 한 이유는 Easter Eggs에 대한 가능한 이유 : 보안 문제와 밀접한 관련이 있습니다. 관련 Wikipedia 기사에 요약 된대로이스터 에그는 일반적으로 (적어도 사용자 / 클라이언트에게는) 코드의 문서화되지 않은 부분으로, 제품이 공격에 더 개방적이거나 다른 방식으로 신뢰할 수 없다고 믿게 할 수 있습니다. 또한, 모든 이스터 에그 코드가 "미션 크리티컬"코드와 동일한 수준으로 테스트 및 감사되는 것은 아닙니다. 이로 인해 코드베이스에 발견되지 않은 결함이나 루프 홀이 생길 수 있으며, 이는 이후의 공격 또는 맬웨어 악용의 원인이 될 수 있습니다.

그러나 모든 이스터 에그가 "나쁜"것은 아니며 제품의 실제 코드를 변경해야합니다. 이스터 에그를 표현하는 방법에는 여러 가지가 있는데, 특히 코드가 내용과 약간 분리 된 게임 (게임 / 그래픽 / 스크립트 엔진 대 실제 스크립트 또는 레벨 파일)에서 발생합니다. 이러한 방식은 DN3D에서 사용되는 주인공의 특수 텍스처 / 오브젝트 및 오디오 주석 (예 : DN3D : Doom , Terminator , Indiana Jones , Star Trek )에서 비밀 레벨 ( "소 레벨 없음" )에 이르기까지 특정 오브젝트가있을 때 표시되는 대화 상자 에 이르기까지 다양 합니다. 사용자 인터페이스의 / location 등을 클릭하십시오. 물론 이들 각각이 모든 유형의 제품에 적합한 것은 아닙니다.

이스터 에그를 제품에 넣는 좋은 방법은 크레딧 섹션뿐만 아니라 어떻게 든 자신을 포함시키는 것입니다. Blizzard는 StarCraft 2 와 함께 이것을 아주 잘 해냈습니다 . 하나의 단위 초상화는 실제로 개발자 중 하나의 얼굴입니다. 그다지 명백하지 않은 것은 미디어 지식이나 특정 종류의 유머에 의존하지 않기 때문에 일반적으로 여러 유형의 소프트웨어에 적합합니다. 예를 들어, 제품의 맥락에서 자신을 캐릭터로 포함시킬 수 있습니다. 제품에 따라 코드에 대한 기회가 필요하지 않거나 매우 간단한 코드 일 수도 있습니다.

이스터 에그는 좋은 맛이지만 필수는 아닙니다. 이스터 에그의 구현은 실제 제품을 방해해서는 안되며 최종 제품의 들여 쓰기 된 대상 청중에게 적합해야합니다. "심각한"응용 프로그램 또는 성인이 아닌 사람을 대상으로 한 제품의 이스터 에그는 아무리 재미 있거나 무해한 것으로 보일지라도 성인 유머 나 성적 콘텐츠를 포함해서는 안됩니다. 이는 법적 결과를 초래할뿐만 아니라 소프트웨어의 마케팅 범위에도 영향을 미칩니다 (예 : USK / PEGI / ESRB 등급).

— 베 오른
소스

1

Microsoft가 왜 부활절 달걀을 코드에 넣지 않았 는지 살펴 봐야 합니다. 이스터 에그는 완전히 테스트되지 않은 코드 경로입니다 (이스터 에그에서 전체 QA를 수행 할 기회가 있다면 왜 다른 유용한 기능을 대신 포함시키지 않습니까?) 보안 취약점의 잠재적 원인.

— 아논.

@Anon : 내가 대답 한 Wikipedia 기사에서 : "과거에 Microsoft Office와 같이 가장 크고 정교한 부활절 달걀을 만든 Microsoft는 더 이상 부활절 달걀을 소프트웨어의 일부로 허용하지 않습니다. "신뢰할 수있는 컴퓨팅 이니셔티브" 그 진술의 출처는 Charles의 답변에 링크 된 MSDN 블로그 기사입니다. 나는 나의 진술과 모순되는 것을 보지 못했다. 내가 어디에서 잘못했는지 설명해 주시겠습니까? :)

— Baelnorn

대답의 첫 번째 부분은 "이봐, 마이크로 소프트가 이렇게했던 것이 굉장하지 않습니까?"와 같지만 더 이상 그렇게하지 않는 실제 이유는 답의 중간에 묻 힙니다. 우연한 독자는 그것을 보지 않을 것이며 관련 컨텍스트에서 연결이 끊어졌습니다. 이상적으로는 단락을 좀 더 눈에 띄게 배치하기 위해 단락을 재구성하고 싶습니다.

— 아논.

@Anon : 고마워요. 나는 첫 번째 부분에서 EE에 대한 이유를 자세히 설명하면서 대답을 편집하고 단락을 재정렬했습니다.

— Baelnorn

5

부활절 달걀은 80 년대와 90 년대 주요 상용 소프트웨어 릴리스에서도 일반적이었습니다. 대부분은 귀엽고 상대적으로 소수의 사람들이 괴롭 혔습니다. 나는 오늘날 세 가지 이유로 덜 일반적이라고 생각합니다.

모든 실제 농담과 마찬가지로 누군가 눈을 끌 때까지 재밌습니다. 이스터 에그에 데이터 손실이나 성능 문제를 일으키는 버그가있는 경우 실제로는 "맬웨어"를 배포하지 않았다는 사실을 많은 변호사에게 설명해야 할 수도 있습니다.
유머는 매우, 매우, 옳은 일을하기가 어렵고, 잘못하면 고객에게 돈을 지불하고 소프트웨어에 대한 비용을 지불하지 않을 것이며, 당신이 일하는 끔찍하고 미성숙 한 회사에 대해 언론에 불쾌한 편지를 많이 쓸 것입니다 에 대한. Ctrl-FU에 의해 유발 된 부활절 달걀의 예는 완벽한 예입니다. 17 살짜리 친구들에게는 아마도 재미있을 것 같지만, 농담으로 고객에게 "FU"라고 말하지 않는 것은 마케팅의 0 번째 규칙입니다. 큰 상용 소프트웨어의 이스터 에그는 결코 경쟁자만이 사용자를 놀리지 않았습니다.
영화 헤드 에있는 Monkees의 Peter Tork의 불멸의 말에서 "아무도 유머 감각이있는 사람에게 돈을 빌려주지 않습니다." 중요한 소프트웨어 인프라를 구입하는 경우 저자의 유머 감각은 안심할 수 없습니다. 게다가 왜 그들은 수많은 보안 버그를 고칠 수 있었을 때 부활절 달걀을 쓰는 데 시간을 보냈습니까?

Larry Osterman은 몇 년 전 Microsoft의 OS 그룹이 더 이상 부활절 달걀을 허용하지 않는 이유에 대해 꽤 유명한 블로그를 가지고있었습니다 .

— 찰스이 그랜트
소스

1

오늘날에도 구글은이 부활절 달걀 - 각 검색에 부활절 달걀을 트리거 입력을 위해 그들이있는 거 검사를 의미한다. 처리가 많지는 않지만 매일 처리하는 수억 건의 검색을 고려하면 알 수 없습니다.

— Charles Salvia

CTRL-FU를 일종의 KUNG-FU로 읽었다 고 고백해야합니다.

— Christopher Creutzig

@Christopher는 완벽하게 합리적인 해석입니다. 유머는 종종 여러 가지 해석의 대상이되기 때문에 누군가를 화나게 할 위험을 감수하지 않고 소프트웨어에 포함시키는 것이 까다로운 이유 중 하나입니다.

— Charles E. Grant

@CharlesSalvia 검색 결과를 처리하여 "당신은 의미 했습니까?"결과를 결정하는 방법에 따라 해당 동작에 대해 이미 존재하는 것 위에 오버 헤드가 전혀 발생하지 않을 수 있습니다.

— JAB

4

부활절 달걀은 건축업자가 남긴 비밀입니다. 최종 사용자에게 상처를 주나요? 아니.

많은 유명 하고 인기있는 소프트웨어의 조각 포함 한 부활절 달걀을 숨겨 . 이스터 에그는 또한 특정 감동적인 주제 에 대한 개발자의 감정을 다소 우아한 방식 으로 표시하는 데 사용되었습니다 .

코드 최적화와 관련하여 부활절 달걀이 너무 집중적이지 않는 한 (hello flight simulator ) 의미있는 방식으로 성능을 손상시키지 않아야합니다.

— 조쉬 케이
소스

동의하지 않습니다. 이스터 에그는 사용자에게 피해를 줄 수있는 이벤트 발생 위험을 추가합니다. 기껏해야 이러한 "추가 기능"은 테스트를 거쳤으며 개발자와 QA의 가동 시간 만 사용합니다. 최악의 경우, 구현 자 외에는 아무도 그것에 대해 알지 못합니다. 구현자는 나중에 회사를 떠난 후 소프트웨어 업데이트로 인해 의도하지 않게 이스터 에그가 키보드 이벤트 차단, 사용 가능한 모든 RAM 사용 또는 극단적 인 경우 ... 하드 드라이브. 오버 탑? 아마도. 그러나 나는 이것들 각각이 정상적인 버그로 발생하는 것을 보았습니다.

— mummey

@mummey : 그럴 가능성이 거의 없다고 생각합니다.

— Josh K

그러한 위험을 완화하기 위해 최선을 다하지 않겠습니까?

— StuperUser

@Stuper : 이스터 에그가 프로그램을 중단한다고 들었습니까?

— Josh K

전혀 알지 못하지만 부활절 달걀의 충돌은 대부분 문제의 게시를 보증하기에 충분하지 않습니다. 사용자는 보통 정상적인 작동 중에 대부분의 MS 프로그램 충돌에 대한 정보를 다시 보내지 않습니다 .

— StuperUser

2

소프트웨어에서 이스터 에그를 좋아하지만 재미를 위해 제품에 남은 알과 악의적 인 백도어 사이의 경계선은 법적인 관점에서 볼 때 매우 얇을 수 있다는 것을 기억하는 것이 중요합니다. 예를 들어, 해를 입힐 필요가 있습니까? 해를 끼칠 의도를 증명해야합니까?

법원이 컴퓨터와 소프트웨어에 대한 이해가 상당히 비참하다는 점을 고려할 때 (일부 소프트웨어 특허에 의해 입증 된 바와 같이) 그러한 사건에 대한 토론은 여러 변호사를 아스펜의 멋진 휴가지로 사줄 것입니다. 소프트웨어가 전 세계에 게시되고 배포되는 다양한 법적 환경 (예 : DMCA)을 고려할 때 알프스에서 휴가 용 주택을 구입할 수도 있습니다.

우리는 고용 된 엔지니어로서 우리 회사에 아무런 해를 끼치 지 않는다고 보증합니다. 계약이 다른 클라이언트, 특히 정부 나 대기업에 소프트웨어를 제공하면 소송이 피해를 입을 수 있으며 소송이 발생할 가능성이 있습니다. 따라서 저는 개인적으로 안전한 편에서 실수를하기로했습니다.

엔지니어들은 논리를 선한 목적으로 사용해야하지만, 변호사들은 논리를 악의로 돌리기 위해 존재한다는 것을 기억하십시오. 그래서 그들은 우리보다 훨씬 더 많은 돈을받습니다.

— 우리
소스

0

많은 사람들이 이스터 에그가 게임에 더 적합하다고 말했지만 비즈니스 응용 프로그램에서 사용한다고 생각합니다. 너무 많은 사람들은 비즈니스 응용 프로그램을 사용하여 응용 프로그램의 다른 영역을 보지 않는 일련의 요리법을 만듭니다. 나는 그들이 훈련의 일부가 아니었다면 결코 보지 않는 응용 프로그램의 전체 섹션이 있으며 그것들이 유용 할 수 있음을 의미합니다. 현재 75 개의 보고서가있는 응용 프로그램을 작업했으며 사용자가 정보를 요청했으며 단일 보고서를 실행하지도 않았습니다. 호기심이 부족한 부분을 보충하기 위해 약간의 인센티브가 필요합니다.

— 제프
소스

-2

부활절 달걀을 사용하여 디버그 및 코딩에 도움을줍니다. 따라서 내가 넣은 부활절 달걀은 목적을 제공하며 아마도 부활절 달걀으로 간주되지 않을 것입니다.

— 데이브
소스

사용법에서 '부활절 달걀'이란 정확히 무엇을 의미합니까? 예를 들어 주시겠습니까?

이것은 부활절 달걀이 아니라 백도어입니다. 도구가 화면 위치 (0,0)에서 마우스 가운데 버튼을 두 번 클릭 한 다음 올바른 비밀번호를 입력 할 때 GUI 테스트를 위해 특별한 작업을 수행합니다. 이것은 GUI 자동화 도구가 처리 할 수 있도록하기위한 것입니다. 사용자는 이론적으로도이 작업을 수행 할 수 있지만 실제로는 도달하지 못합니다. 또한, 사방에 경고 표시가 있습니다.

— 직업

1

@Glenn, 데스크톱 GUI 응용 프로그램을 제공하는 경우 좋은 예입니다. 사용자가 버튼을 클릭하면 새 대화 상자가 나타납니다. 사용자가 Shift 키를 누른 상태에서 해당 단추를 클릭하면 이전 단추가 나타납니다. 새 위젯으로 인한 버그를 수정하려고 할 때 이전 기능과 새 기능을 비교하는 좋은 방법입니다. 신중한 경우 이중 코드는 그대로두고 백도어는 주석 처리 할 수 있습니다. 그런 다음 사물을 디버깅해야하므로 주석을 해제하고 다시 빌드하면 두 가지를 나란히 비교할 수 있습니다. 데이브, 천둥을 훔쳐서 미안해

— 직업