초록 빛이 있고, 정리하기 위해 누군가가 GameManager를 작성합니다. 아마도 많은 GameState를 보유하고있을 수도 있고, 실제로는 크지 않은 몇 개의 GameObject를 저장할 수도 있습니다. 귀엽고 작은 매니저
내가 이것을 읽을 때, 나는 머리에 작은 경보가 울렸다. "GameManager"라는 이름의 오브젝트는 결코 귀엽거나 작을 수 없습니다. 그리고 누군가 코드를 정리하기 위해 이것을 했습니까? 전에는 어땠나요? 좋아, 농담은 제쳐두고 : 클래스의 이름은 클래스의 역할을 명확하게 나타내야하며 이것은 하나의 책임 이어야합니다 (일명 책임 원칙 ).
또한 GameManager와 같은 객체가 여전히 생길 수 있지만 분명히 매우 높은 수준으로 존재하므로 높은 수준의 작업과 관련이 있습니다. 게임 오브젝트의 카탈로그를 유지합니까? 혹시. 게임 개체 간의 커뮤니케이션을 촉진 하시겠습니까? 확실한. 객체 간 충돌을 계산합니까? 아니! 그렇기 때문에 이름 관리자 가 눈살을 찌푸리는 이유도 있습니다. 너무 광범위해서 배너 아래에서 많은 악용이 가능합니다.
수업 규모에 대한 간단한 경험 법칙 : 수업 당 수백 줄의 코드를 실행하면 문제가 발생하기 시작합니다. 300 LOC는 지나치게 열악하지 않고 코드 냄새가 나며, 1000 개가 넘으면 경고음이 울려 야합니다. 어떻게 든 1000 줄의 코드가 각각 250 개의 4 개의 잘 구조화 된 클래스보다 이해하기 쉽다고 믿으면서 스스로를 속이고 있습니다.
시간이 문제가 될 때 별도의 수업을 쓰거나이 거대한 관리자를 하위 관리자로 나눌 수 없습니다.
문제가 모든 것이 엉망인 지점으로 전파 될 수 있기 때문에 이것이 사실이라고 생각합니다. 의 연습 리팩토링은 - 당신이 찾고있는 무엇을 정말 당신은 지속적으로 작은 단위로 코드의 디자인을 개선하기 위해 필요합니다 .
이런 일이 발생하지 않도록 무엇을 제안 하시겠습니까?
문제는 기술적 인 문제가 아니므로 기술적 인 문제를 찾아서는 안됩니다. 문제는 이것입니다. 팀에서 모 놀리 식 코드 조각을 만드는 경향이 있으며, 이와 같이 작동하는 것이 중장기 적으로 유리하다는 믿음이 있습니다. 또한 팀에는 강력한 아키텍처 리더가 부족하여 게임의 아키텍처를 조정합니다 (적어도이 사람은이 작업을 수행하기에는 너무 바쁩니다). 기본적으로, 유일한 방법은 팀 구성원이이 생각이 잘못되었음을 인식하도록하는 것입니다. 아무도 호의를 베풀지 않습니다. 제품의 품질이 떨어지고 팀은 물건을 수리하는 데 더 많은 밤을 보낼 것입니다.
좋은 소식은 깨끗한 코드 작성의 즉각적이고 실질적인 이점이 너무 커서 거의 모든 개발자가 자신의 이점을 매우 빠르게 인식한다는 것입니다. 팀이 한동안 이런 식으로 일하도록 설득하면 결과는 나머지 작업을 수행합니다.
어려운 부분은 나쁜 코드를 구성하는 요소에 대한 느낌을 개발하는 것 (그리고 더 나은 디자인을 빠르게 만들 수있는 재능)이 개발에서 배우기가 더 어려운 기술 중 하나라는 것입니다. 내 제안은 당신이 이것을 할 수있는 팀에 선임자가 있다는 희망에 달려 있습니다. 사람들을 그렇게 설득하는 것이 훨씬 쉽습니다.
편집-조금 더 많은 정보 :
일반적으로 귀하의 문제는 게임 개발에만 국한되지 않는다고 생각합니다. 핵심은 소프트웨어 엔지니어링 문제이므로 그 방향에 대한 의견입니다. 다른 유형의 개발보다 더 많은 결과와 마감일을 지향하는지 여부에 관계없이 게임 개발 산업의 성격이 다를 수 있습니다.
그러나 특히 게임 개발의 경우 "특히 게임 아키텍처"팁과 관련하여 StackOverflow에 대한 이 질문 에 대한 대답 은 다음과 같습니다.
객체 지향 디자인 의 견고한 원칙을 따르십시오 ....
이것은 본질적으로 내가 말하는 것입니다. 압력을 받고있을 때, 나는 또한 큰 코드를 작성하고 있다는 것을 알게되었지만 기술 부채라는 것을 내 머리에 뚫었습니다. 나를 위해 잘 작동하는 것은 하루 중 상반기 (또는 4 분의 3)를 대량의 중간 품질 코드를 생성 한 다음 잠시 후 다시 생각하고 생각하는 것입니다. 코드를 약간 향상시키는 방법에 대해 머리 또는 종이 / 화이트 보드에서 약간의 디자인을하십시오. 종종 반복적 인 코드를 발견하고 실제로 가독성을 향상시키면서 모든 것을 줄임으로써 전체 코드 줄을 줄일 수 있습니다. 이번 투자는 너무 빨리 돈을 지불하여 "투자"라고하는 것은 어리석은 소리로 들립니다. 아주 자주 나는 하루 종일 (1 주일 후) 낭비했을 수있는 버그를 발견 할 것입니다.
- 코딩 한 당일에 문제를 해결하십시오.
- 몇 시간 안에 기뻐하실 것입니다.
실제로 위의 내용을 믿기가 어렵습니다. 나는 효과를 반복해서 경험했기 때문에 내 일을 위해서만 해냈습니다. 그럼에도 불구하고 더 많은 정보를 얻을 수있을 때 코드 수정을 정당화하는 것은 여전히 어렵습니다 ... 그래서 나는 당신이 어디에서 왔는지 확실히 이해합니다. 불행히도이 조언은 너무 일반적 일 수 있으며 쉽지 않습니다. 그러나 나는 그것을 강력하게 믿는다! :)
구체적인 예를 들면 다음과 같습니다.
Uncle Bob의 Clean Code 는 양질의 코드가 어떤 것인지 요약하는 놀라운 일을합니다. 나는 거의 모든 내용에 동의합니다. 따라서 30 000 LOC 관리자 클래스의 예를 생각할 때 "좋은 이유"부분에 실제로 동의 할 수 없습니다. 나는 불쾌하게 말하고 싶지 않지만 그런 식으로 생각하면 문제가 발생할 수 있습니다. 단일 파일에 많은 코드를 넣을 이유가 없습니다. 거의 1000 페이지의 텍스트입니다! 로컬 리티 (실행 속도 또는 디자인 "단순성")의 이점은 개발자가 그 괴물을 탐색하려고 완전히 쇠약 해져서 즉시 무시됩니다.
확신이 없으면 위의 책의 사본을 들고 살펴 보는 것이 좋습니다. 이러한 유형의 사고를 적용하면 사람들이 자발적으로 깨끗하고 자명 한 코드를 만들 수 있습니다.