MVC 및 TDD가 게임 아키텍처에서 더 이상 사용되지 않는 이유는 무엇입니까? [닫은]

나는 많은 양의 게임 소스를 보지 않았고 게임 방식으로 많이 만들지 않았다고 말함으로써 이것을 서두를 것입니다.

그러나 웹 응용 프로그램에서 '엔터프라이즈'코딩 방법을 사용하려고 시도 할 때 게임 소스 코드를 보면 "이 논리가 비즈니스 논리와 관련하여 무엇을 하는가? 리팩토링이 필요합니다." "

게임 프로젝트를 시작하려고 할 때 걱정이되며, dev 프로세스를 mvc / tdd하려고하면 우리를 방해하거나 도울 것인지 확실하지 않습니다.이를 사용하는 많은 게임 예제가 보이지 않기 때문에 또는 지역 사회에서 더 나은 건축 관행을 요구합니다.

다음은 프로토 타이핑 게임에 대한 훌륭한 기사에서 발췌 한 내용 이지만, 많은 게임 개발자들이 프로덕션 게임 코드를 작성할 때 사용하는 태도와 똑 같았습니다.

실수 # 4 : 게임이 아닌 시스템 구축

... 당신이 직접 앞으로 나아 가지 않는 일을하고있는 것을 발견했다면, 바로 거기에서 멈추십시오. 프로그래머로서 우리는 코드를 일반화하고 우아하게 만들고 모든 상황을 처리 할 수있는 경향이 있습니다. 우리는 가려움증이 긁히지 않는 것이 아니라 방법을 알아야합니다. 코드가 아니라 결국에 제공하는 게임에 관한 것임을 깨닫는 데 몇 년이 걸렸습니다.

우아한 게임 구성 요소 시스템을 작성하지 말고 편집기를 완전히 건너 뛰고 코드로 상태를 고정 시키십시오. 데이터 중심의 자체 구문 분석, XML 크래시를 피하고 저주받은 것을 코딩하십시오.

... 가능한 한 빨리 화면에 물건을 넣으십시오.

그리고“시간이 더 걸리고 올바른 방법으로하면 게임에서 재사용 할 수 있습니다”라는 주장을 절대 사용하지 마십시오. 이제까지.

게임이 (주로) 시각적으로 지향되어 있기 때문에 코드의 가중치가 무거워서 물건을 모델 / 컨트롤러로 옮길 때 얻을 수있는 이점이 매우 적기 때문에 왜 귀찮습니까?

MVC가 성능 오버 헤드를 발생 시킨다는 주장을 들었지만, 이는 조기에 최적화 된 것으로 보이며 MVC 오버 헤드 (예 : 렌더 파이프 라인, AI 알고리즘, 데이터 구조)에 대해 걱정하기 전에 해결해야 할 더 중요한 성능 문제가 있습니다. 순회 등).

TDD에 대해서도 마찬가지입니다. 테스트 사례를 사용하는 게임을 자주 볼 수는 없지만 위의 디자인 문제 (혼합보기 / 비즈니스)와 시각적 구성 요소 또는 확률 적 결과에 의존하는 구성 요소 (예 : 물리 시뮬레이션 내에서 작동)를 테스트하기 어렵다는 사실 때문일 수 있습니다. ).

아마도 잘못된 소스 코드를보고 있는데 왜 게임 디자인에 이러한 '엔터프라이즈'관행이 더 많이 보이지 않습니까? 게임의 요구 사항이 실제로 다른가요? 아니면 사람 / 문화 문제 (게임 개발자가 다른 배경에서 왔으므로 코딩 습관이 다름)입니까?

인용에서 알 수 있듯이 많은 프로그래머는 게임이 아닌 시스템을 구축하려고 시도합니다. 일반적으로이 시스템은 이론적 으로 모든 것을 처리 할 수있을 정도로 복잡 할 때까지 풍선 모양을 유지 하지 못하지만 실제로는 모든 코드 묶음이 있습니다. 또는 작업 단계에 도달하기 전에 실행하지 않는 코드에 너무 얽혀서 초점을 잃을 수 있습니다 (시작해야 할 경우).

프로토 타입과 반복은 훨씬 더 잘 작동하는 경향이 있습니다. 결국 훌륭한 디자인이 나올 수도 있지만 더 간결하고 세련된 무언가가 나올 수도 있습니다. KISS 와 YAGNI 가 떠 오릅니다.

나는 개인적으로 균형이 필요하다고 믿는다. 게임의 핵심 메커니즘이 있다면 작업하십시오. 여전히 반복해야하지만 다듬어야합니다. 힌트 : 코드 구성은 게임의 핵심 메커니즘이 아닙니다.

적절한 예 : PopCap Games의 Peggle 이 게임의 핵심 메커니즘은 공 물리입니다. 그들은 그것을 완성했습니다! 나는 그것이 게임을 만드는 이유이기 때문에 완벽하게 완벽하다는 것을 확신하기 위해 많은 시간을 보냈다고 확신합니다. 그러나 동시에 게임 스프라이트를 화면에 끌어 들이고 게임의 아이디어가 재미 있는지 확인하기 위해 좀 더 기본적인 충돌 감지 및 수신 거부를 수행하는 초기 게임 프로토 타입을 완전히 그림으로 그릴 수 있습니다. 그런 다음 공을 쏴서 튀는 것을 보는 것이 실제로 재미 있다는 것을 알게되면 공의 튀는 부분을 개선했습니다. _{(물론 이것은 단지 추측 일뿐입니다)}

또한 기술 요구 사항에 따라 달라집니다. 게임 디자인이 아니라 기술 요구 사항 만 조기에 해결해야합니다. 게임이 실행되는 플랫폼이 변경되어서는 안되며, 변경이 허용되어야하는 경우, 게임을 변경할 수있는 정도를 정확히 알아야합니다. 그것에 디자인하십시오. OpenGL 용 게임을 개발 중이고 DirectX에 관심이 없다면 실제로 신경 쓰지 마십시오. 즉, 각 엔티티가 자체적으로 그려지고 팩토리 및 기타 디자인 패턴에 대해 걱정하지 않는 것이 더 편리하다면 그렇게하십시오. 요구 사항을 충족하기 때문에 괜찮습니다. 자신의 말에도 불구하고 나중에 변경할 필요는 없습니다. 그리고 실제로 최악의 시나리오는 무엇입니까? 나중에 리팩터링하십시오.토스터에서 동시에 자동으로 실행할 수없는 경우에도 하나의 플랫폼에서 작동하는 게임을받을 수 있습니다.

그러나 테스트 중심 디자인은 더 의견이 많은 주제입니다. 게임 개발자가 더 많은 일을해야한다고 생각합니다. 또한 게임 개발자는 가장 엄격하고 빡빡한 일정을 가지고 있다고 생각하며 게임을 원할 때 TDD에 시간을 할애 할 수 없다고 생각합니다. 또한 TDD는 동기 부여를 통해 훨씬 느리게 작동하며 (적어도 처음에는) 작동하는 게임을 훨씬 덜 보게됩니다. 이것은 프로그래머 동기 부여에 심각한 부정적인 영향을 줄 수 있습니다.

나는 또한 지식과 실습의 일반적인 부족이라고 생각합니다. TDD가 다른 분야에서도 널리 퍼져 있다고 생각하지는 않지만 민첩한 개발과 마찬가지로 확산되고 있다고 생각합니다. 당신은 시간보다 앞서 있다고 말할 수도 있습니다. TDD보다 더 중요한 것은 "RDD"-요구 사항 중심 개발입니다. _{방금 만들었습니다.}당신의 목표는 무엇입니까? 게임을 만들려면 다른 모든 것이 두 번째입니다. TDD가 생산성을 높이고 팀이 마감일에 도달하는 데 도움이된다는 것을 증명할 수 있다면 모든 사람이이를 사용한다고 생각하지 않습니까? 아마도 그럴 수도 있습니다. 그러나 현재 우리 업계는 그 어느 때보 다 경쟁이 치열하고 마감일이 더 빠르며 작업이 필요합니다. 건설 노동자는 비계를 먼저 건설하지 않습니다. 그들은 기초를 세우고 벽과 바닥을 올린 다음 비계가 더 편리한 특정 작업을 수행하기 위해 선택적 비계를 만듭니다. 소프트웨어 개발에도 동일하게 적용됩니다.

이렇게 긴 글에 대해 죄송합니다. 나는 당신이 그것으로부터 약간의 지혜를 얻었기를 바랍니다. 나는 단지 경험이 매우 제한적이지만 업계 전문가로부터 많은 것을 읽은 나의 관찰에 대해 이야기하는 학생 일뿐입니다. 소금 한알로 내 말을 들어라.

그리고 당신이 생각하는대로 행동하십시오. 언제든지 변경하거나 폐기하고 다시 시작할 수 있습니다. 그것은 모든 형태의 공학에서 멋진 일입니다. 처음에 성공하지 못하면 다른 것을 시도하십시오. (또는 그와 비슷한 것 : -P) 콘크리트를 따르지 않습니다. 소프트웨어는 가단성입니다.

그건 그렇고, 나는 같은 유형의 질문을하고 한동안 이러한 유형의 디자인 원칙을 연구했습니다. 여기와 스택 오버플로에 관련된 몇 가지 질문이 있습니다.

• "MVC 패턴에 맞게 게임 코드를 어떻게 구성 할 수 있습니까?"
• "단위 테스트가 용이하도록 게임 소프트웨어를 설계하는 방법은 무엇입니까?"
• "컴포넌트 기반 게임 엔진 디자인"
• "확장 가능하고"구성 요소 "기반 게임 '프레임 워크'를 디자인하는 방법을 배우기위한 훌륭한 자습서 또는 리소스가 있습니까?"
• "게임 및 렌더링 로직 분리"
• "게임 프로그래밍에서 유닛 테스트가 가능합니까?"
• "상업용 컴퓨터 게임에 사용되는 MVC 디자인 패턴"
• "테스트 중심 개발이 게임 개발에서 일반적인 접근 방식입니까?"
• "게임 개발에 Scrum을 사용하는 사람이 있습니까?"
• "게임을위한 건축-커플 또는 커플?
• "OO 게임 디자인 질문"

다음 은 적어도 질문의 MVC 부분에 관한 SO 와 비슷한 질문 에 대한 원래의 대답입니다 .

게임에서는 거의 사용되지 않습니다. 이유를 알아내는 데 시간이 걸렸지 만 여기에 내 생각이 있습니다.

MVC는 두 표현을 구별하기 위해 존재합니다. 모델은 데이터의 추상 표현입니다. 머신이 애플리케이션의 상태를 보는 방식입니다. 뷰 (및 컨트롤러)는 인간에게 의미있는 방식으로 해당 시스템의보다 구체적인 가시화 인스턴스를 나타냅니다.

대부분의 비즈니스 앱에서이 두 세계는 매우 다릅니다. 예를 들어 스프레드 시트의 모델은 단순히 2D 값 그리드입니다. 셀의 너비, 픽셀, 스크롤 막대 등을 생각할 필요가 없습니다. 동시에 스프레드 시트보기는 셀 값의 계산 또는 저장 방법을 모릅니다.

게임에서이 두 세계는 서로 훨씬 더 가깝습니다. 게임 세계 (모델)는 일반적으로 가상 공간에 위치한 일련의 개체입니다. 게임 뷰는 일부 가상 공간에 위치한 엔티티 세트입니다. 경계 볼륨, 애니메이션, 위치 등 "뷰"의 일부로 간주 할 모든 것은 "모델"에서도 직접 사용됩니다. 애니메이션은 물리 및 AI 등에 영향을 줄 수 있습니다.

최종 결과는 게임에서 모델과 뷰 사이의 선이 임의적이며 도움이되지 않는다는 것입니다. 당신은 그들 사이에 많은 상태를 복제하게됩니다.

대신 게임은 도메인 경계를 따라 사물을 분리하는 경향이 있습니다. AI, 물리, 오디오, 렌더링 등은 가능한 한 분리되어 유지됩니다.

MVC는 게임 아키텍처에 맞지 않기 때문입니다. 게임의 데이터 흐름은 엔터 프라이스 응용 프로그램의 데이터 흐름과 완전히 다릅니다. 이벤트 중심이 아니고 종종 이러한 작업을 수행하는 데 필요한 밀리 초 예산이 있기 때문입니다. 16.6 밀리 초 안에 발생해야하는 많은 것들이 있으므로 정확한 시간에 화면에 필요한 데이터를 처리하는 '고정 된'데이터 파이프 라인을 갖는 것이 더 유리합니다.

또한 분리가 있습니다. 대부분의 경우 MVC 패턴과 같은 방식으로 연결되지 않습니다. 렌더링 엔진 (View), 사용자 입력 처리 (Controller) 및 게임 플레이 로직, 인공 지능 및 물리학 (Model)과 같은 나머지가 있습니다. 생각해보십시오. 사용자 입력을 가져오고 ai를 실행하고 초당 60 회 이미지를 렌더링하는 경우 모델과 뷰 사이에 옵저버가 필요한 이유는 무엇입니까? 게임에서 옵저버 패턴이 필요하지 않다고 말하는 것으로 이것을 해석하지 마십시오. 그러나이 경우에는 실제로 필요하지 않습니다. 어쨌든 모든 작업, 모든 프레임을 수행하고 있습니다.

TDD는 개발 스튜디오에서 거의 사용되지 않지만 소프트웨어 개발에는 애자일 관행을 사용하며 SCRUM은 유럽에서 적어도 인기있는 선택 인 것 같습니다. 이유는 간단하다. 변화는 어디에서나 온다. 아티스트들은 더 많은 텍스처 예산, 더 큰 세계, 더 많은 나무를 원할 것입니다. 디자이너들은 더 풍부한 스토리 (디스크의 더 많은 콘텐츠), 스트리밍 세계를 원하고 출판사는 시간과 예산에 따라 마케팅 부서를 마치기를 원합니다. 그 외에도 "최첨단 기술"은 빠르게 변화하고 있습니다.

그렇다고 우리가 테스트를하지 않는다는 것은 아닙니다. 대부분의 스튜디오에는 대규모 Q & A 부서가 있고, 많은 회귀 테스트를 실행하고 정기적으로 단위 테스트를 수행합니다. 그러나 단위 테스트를 수행 할 수없는 버그는 대부분 아트 / 그래픽 관련 (충돌 메시의 구멍, 잘못된 텍스처, 필드 심도의 결함)과 관련이 있기 때문에 단위 테스트를 사전에 수행 할 요점이 거의 없습니다. 또한 작업 코드 외에도 모든 게임 의 가장 중요한 요소는 재미 있고 단위 테스트가 없다는 것입니다.

또한 콘솔 세계에서는 하드웨어에 대한 것보다 다른 프로그래밍에 대한 프로그래밍이 많기 때문에 여전히 다릅니다. 이것은 일반적으로 (PS2 / PS3) 데이터 흐름이 거의 모든 경우 코드의 흐름보다 훨씬 중요하다는 것을 의미합니다. 성능 고려 사항으로 인해. 대부분의 경우 TDD를 아키텍처 도구로 사용하지 않습니다. 좋은 OOP 코드는 일반적으로 데이터 흐름이 좋지 않아 벡터화 및 병렬화가 어렵습니다.

MVC 및 TDD가 게임 아키텍처에서 더 이상 사용되지 않는 이유는 무엇입니까?

경고 : 의견이 있습니다.

MVC는 다음과 같은 이유로 많이 사용되지 않습니다.

1. MVC는 비교적 새로운 접근 방식이며 게임은 일반적으로 오래된 코드를 기반으로합니다. MVC 앱을 만드는 대부분의 사람들은 매번 아무 것도 만들지 않습니다. (MVC 자체는 실제로 수십 년이 걸렸다는 것을 알고 있습니다. 새로운 것은 근본적으로 RoR과 같은 웹 응용 프로그램에서 나온 것에 대한 관심입니다.) 내가 일한 비즈니스 소프트웨어에서는 레거시 코드를 기반으로했지만 MVC도 사용되지 않았습니다. 그것은 문화적인 것이지만 게임마다 다릅니다.
2. MVC는 기본적으로 이벤트 중심 프로그램의 GUI 패턴입니다. 게임은 GUI 나 이벤트 중심이 아니므로 웹 응용 프로그램이나 다른 폼 기반 응용 프로그램만큼 유용하지 않습니다. MVC는 일반적으로 잘 알려진 역할을 가진 관찰자 패턴이며, 게임은 종종 흥미로운 것을 관찰하기를 기다리는 사치를 누리지 못합니다. .

게임이 MVC로부터 많은 것을 배울 수 없다는 것은 아닙니다. 나는 항상 내가 만드는 게임에서 모델을보기와 분리하려고 시도합니다. 뷰와 컨트롤러가 동일한 (위젯) 객체의 두 부분이라는 전통적인 아이디어는 실제로 작동하지 않으므로 조금 더 추상적이어야합니다. 나는 여기서 성능이 실제 문제가되지 않을 것이라는 데 동의합니다. 시각적 성능과 로직 기능을 분리하여 유지하는 것이 성능에 도움이된다면 일관성, 병렬 처리 등을 캐시하는 것이 더 적합합니다.

TDD는 다음과 같은 이유로 많이 사용되지 않습니다.

1. 게임에서 사용하기가 정말 어색합니다. 다시 말하지만, 입력이 들어오고 출력이 나오는 이벤트 중심 소프트웨어에는 좋습니다. 예상 한 것과 비교 한 내용을 정확하게 비교할 수 있습니다. 많은 양의 공유 상태를 가진 시뮬레이션의 경우 훨씬 더 어색합니다.
2. 그것이 무엇이든 도움이된다는 확실한 증거는 없습니다. 많은 주장과 일부 수치는 종종 자기보고와 권위에 대한 호소에 근거합니다. 아마도 그것은 가난한 프로그래머가 평범한 사람이되는 데 도움이되지만 좋은 프로그래머를 보유하고 있습니다. 테스트 작성에 소요되는 시간은 SOLID 원리를 배우거나 처음에 올바른 인터페이스를 설계하는 데 더 효율적일 수 있습니다. 아마도 객체가 옳은 일을 수행하기에 충분한 테스트가 있다는 실제 증거없이 테스트를 통과하는 것은 잘못된 보안 감각을 제공합니다.

다시 한 번 경고하지만, 단위 테스트는 훌륭하다고 생각하지만 "먼저 테스트"가 유익하거나 합리적이라고 생각하지 않습니다. 또한 초당 여러 번 변경되는 공유 상태가 너무 많을 때 주 시뮬레이션을 테스트하는 것이 실용적이라고 생각하지 않습니다. 일반적으로 테스트를 저수준 및 라이브러리 코드로 제한합니다.

그러나 짐작할 수 있듯이, 기업은 초과 규모와 예산으로 잘 알려져 있기 때문에 " '기업'코딩 관행"에 크게 편향되어 있습니다. "게임 개발자들도!" 네 말을 들었어-그래 저는 현재 소프트웨어를 개발하는 가장 좋은 방법을 아는 사람이 없다고 생각하며, 주류 소프트웨어에서 체계적인 관행을 채택하는 것이 엔터테인먼트 소프트웨어의 자유로운 관행에서 한 단계 더 나아가고 있다고 확신하지 않습니다. 사실 나는 이러한 접근 방식이 더 높은 높이로 올라가는 사다리가 아니라 너무 낮아지지 않는 안전망 인 범용 Java 프로그래머에 의존하는 사람들에게 주로 이익이된다고 생각합니다.

Kylotan은 "게임에서는 프리젠 테이션 측면을 HTML 및 CSS와 같은 분리 가능하고 교체 가능한 개념으로 웹 애플리케이션 용으로 취급 할 수 없습니다"라고 말합니다. 간단한 MVC 패턴 (거대한 프레임 워크가 아님)을 사용하여 몇 가지 게임을 만들었으므로 주요 문제는 모델이 뷰에 대해 알아야한다는 것입니다. 충돌 감지 (또는 다른 유사한 작업)를 해결하는 데 도움이되도록 아트 자산의 스프라이트 비트 맵 데이터, 히트 박스 데이터 또는 3D 지오메트리 데이터를 사용해야 할 가능성이 큽니다. 즉, 각 모델에는 해당 뷰에 대한 참조가 필요하므로 기존 MVC 패턴이 깨집니다. 예를 들어 기존 모델에 대한 새 뷰를 더 이상 만들 수 없습니다.

Unity3D와 같은 컴포넌트 모델은 게임 코드를 구성하는 가장 좋은 방법입니다.

일부 수준에서 MVC는 이미 게임 개발에 사용됩니다. 그것은 입력과 그래픽에 대해 다른 인터페이스를 가진 OS에 의해 강제됩니다. 대부분의 게임에는 물리 분리, 렌더링 및 입력 스레드와 같은 MVC 인스턴스가 몇 개 더 있습니다. 이것은 잘 작동합니다. MVC의 현대적인 아이디어는 더 이상 코드를 이해할 수 없을 때까지 프랙탈로 반복해야한다는 것입니다. 고맙게도 게임은 그렇게하지 않습니다.

TDD는 프로토 타입을 여러 번 반복하기 전에 게임이 "해야 할 것"으로 알려져 있지 않기 때문에 사용되지 않습니다. 지속적인 테스트 나 통합 테스트와 같은 TDD의 사례는 종종 게임 개발에 사용됩니다.

게임 시스템은 더 나은 관행으로 천천히 이동하고 있습니다. XNA와 같은 프레임 워크는 디자인 또는 실행 시간에 너무 많은 오버 헤드를 추가하지 않고도 코드를보다 일반화 / 정리화할 수있는 통찰력을 제공합니다. 그러나 일반적으로 게임 시스템은 복잡한 개발 일정을 유지하고 동기를 유지하면서 복잡성 대 실행 속도를 최적화하는 것입니다. 이러한 환경에서 소프트웨어 엔지니어링 개념과 시스템 설계를 적용하는 것이 우선 순위는 아닙니다.

개인 게임 프로젝트에서 나는 코드에 주석을 달거나 적어도 읽을 수 있도록 노력하고 가능한 한 나중에 (일반성) 좀 더 유연하게 할 수있는 시스템을 함께 던지지 만 하루가 끝나면 당신은 게임을 앞으로 나아 가지 않았고 기분이 좋지 않습니다.

또한 일반적으로 게임을 완료 할 때까지 "재사용 가능한"코드가 거의없는 방식으로 기본 메커니즘, 핵심 시스템 등을 개선하는 방법에 대한 아이디어가 1000 개 이상 있습니다. 정말 사용할 수 있습니다. 하루 하루 나는 정기적 인 SE 직무를 수행하며, 우리가 작업하는 시스템은 방대한 규모 일 수 있지만 솔직히 말하면 게임의 복잡성에 비해 창백하다고 생각합니다.

렌더 루프가 처리 할 하드웨어를 위해 많은 것들을 패키징한다는 단순한 사실에 의해 뷰가 종종 로직과 분리된다는 사실 외에는 MVC에 대한 특별한 의견이 없습니다. 논리 "가 동시에 발생합니다. "컨트롤러"는 하드웨어로도 분리되어 있지만 불행히도 대부분의 게임 개발자가 컨트롤러 처리기에서 "흥미로운"작업을 수행합니다. (IMO 컨트롤러 핸들러는 버튼과 스틱을 읽고 게임에서 볼 수있는 "프레젠테이션"을 작성해야하지만 내 soapbox는 그렇게 강력하지 않습니다.)

반면에 TDD는 매우 강력한 의견을 가지고 있습니다. 개발하기 쉬운 소프트웨어를 만드는 방식으로 개발을 변경하기 만합니다. 의심하기 어려운 것은 어렵습니다. 물론하기가 더 어렵 기 때문에 아직 완료되지 않았습니다. 어떤 사람들은 "게임은 테스트"이기 때문에 가치가없는 TDD (또는 더 일반적으로 단위 테스트)에 대해 우려하지만 TDD에서는 테스트가 거의 관련이 없다는 사실이 있습니다. TDD의 핵심은 프로세스에서 나오는 소프트웨어 디자인 및 아키텍처입니다.

TDD를 수용하면 실제로 프로그래밍 방식이 달라집니다. TDD 경로를 시작하기 전에 옳고 그른 것에 대해 약간의 감정이 있었지만, 일단 두 발로 뛰어 들었을 때, 내가하고있는 일이 미래의 개발을 돕거나 방해하는 방법에 대해 더 많이 이해하게되었습니다. . 실제로 이것은 코드 룸 포스트 뒤에있는 일종의 tDD 없는 TDD 입니다.

왜 어려운 일이 아니라 게임에서 더 많이 사용되지 않는 이유로 돌아가서 사람들은 과거에 항상 해왔 던 방식으로 불필요하게 자신의 일을 더욱 힘들게 만들었으며 프로그래머는 특히 보살 피는 약을 알았습니다. 훨씬 적은 제비.

TDD를 거부하는 사람들은 더 나은 프로그래머가되기를 원하지 않는다고 확신합니다. 그들은 실제로 코드가 완전히 다른 것을 말할 때 프로그래밍이나 디자인 또는 아키텍처에서 "우수"하다고 생각합니다.