효율적인 구조는 웨 필요할까???
게임 개발하는데 굳이 종속성이니 책임이니 역할이니 고민할 필요가 있음???
언더테일 개발자도 1000개가 넘는 switch문으로 개발했다는데 나도 그렇게 하면 안됨????
해도됨 ㅇㅇ
“작동만 하면 되는거 아님??” 마인드의 개발은 단기적으론 좋아보임 장기적으론 기술 부채가 쌓이고 쌓여
나중에 기능을 추가하고 다른 사람과 개발을 하게 될때 그 대가를 지불해야됨. 이를 기술부채라고 하고
이러한 기술부채가 쌓이게 되면 어떻게 될까
유지보수 힘듦
만약 플레이어기능을 구현하는데 하나의 스크립트에 모든 기능을 때려박고 구현을 함.
공격 기능을 사용하니까 하라는 공격은 안하고 상호작용 기능이 실행되서 공격 기능을 담당하는 case를 확인하고 수정을 하니까 이번엔 상호작용 기능이 실행이 안됨. 상호작용 case를 수정하니까 이번엔 플레이어 이동이 안됨 플레이어 이동 case를 수정하니까…
아니 시팔 하나 해결하면 또 하나가 문제가 생기는데 개발하고 싶겠음????
기능 업데이트
개발하고 있는 게임에 기획자가 “와 인붕이님 제가 개쩌는 아이디어가 있는데 몬스터하고 전투만 하는게 아니라 대화로 친구 먹는 기능을 추가하는거 어떰????” 그러면 공격기능 case에 대화하는 case를 추가하고 상호작용 하는 case에 친구먹은 몬스터와 상호작용하는 case도 추가하고….
그렇게 겨우 겨우 기능을 추가하니까 기획자가
“인붕이님 제가 또 개쩌는 아이디어가 있는데 npc도 몬스터 처럼 공격하고 전투하는 기능 추가하죠????”
나같음 자살했음 ㅇㅇ...
그러면 어떡해 개발해야함????
무지성으로 코드를 싸기 전에 몆가지 생각을 해보고 작성해보자
단일 책임 원칙
하나의 클래스는 하나의 책임만.
현재 Player.cs 스크립트 하나가 스탯, 입력, 이동, 공격이라는 4개의 책임을 가지고 있음
기획자가 “인붕이님 제가 개쩌는 아이디어가 있는데 플레이어가 걷는거 말고도 탈것도 타서 이동하게 하는 기능도 추가하죠?????” 라고 해서
이동방식을 수정하고 싶으면 ㅈㄴ큰 Updat 함수를 이해하고 수정해서 구현해야함.
차라리 Player.cs 라는 거대한 스크립트 대신
PlayerStat, PlayerMovement, PlayerInput이라는 class를 만들어서 책임들을 분산하면?.
우리는 기획자가 말한 탈것을 타고 가는 기능을 PlayerMovement만 확인해서 구현하면 된다.
아니면 각 이동하는 방식에 대한 class들을 만들어서 구현하면 된다.
DRY : 반복하지 마셈( Don’t Repeat Yourself)
똑같은 코드를 복사 붙여넣기 하고 있다면 뭔가 잘못되었음.
기획자가 말했던 요구사항들이 여러개 추가되어서 걸어서 이동, 말을 타고 이동, 배를 타고 이동, 할아버지를 타고 이동… 등 10개의 로직들을 MoveToWalk.cs, MoveToRide.cs, MoveToShip…. 으로 나누어서 구현한 인붕이.
근데 기획자가 “인붕이님 제가 개쩌는 아이디어가 있는데 기존의 transform을 통한 이동에서 RigidBody를 이용한 물리 이동으로 변경하는게 좋은것 같은데요??????
모든 이동 로직들의 파일 MoveToRide.cs, MoveToWak.cs, MoveToShip.cs, MoveToGranfa.cs.. 10개의 이동로직 스크립트를 열어서 모두 수정하게 생긴 인붕이…
차라리 이동하는 행동(transform.Translate)로직은 동일하고 수치만 다르니
Mover라는 이동을 가진 class를 하나 만들고 이를 상속해서 구현하면?
****인붕이는 이제 Mover.cs의 Mover메서드만 수정해서 기획자의 요구를 해결할수있다.
즉 DRY의 핵심은 어떻게(이동 방식의 구현)와 무엇(걷기, 탈것)을 분리하는게 핵심
근데 이제 뭐함???????
이론적으론 알겠는데 그래서 뭐 어케함?????????
괜찮다. 나같은 빡대가리도 문제를 해결할수있는 방법을 나보다 더 똑똑한 개발자들이 백1종원 레시피 마냥 해결법들을 풀어놓았다.
이 백1종원 레시피를 디자인패턴이라고 부른다.
이런거 아님
근데 백1종원 레시피대로 요리해도 사람마다 입맛이 다 달라서
“아오 시팔 백종팔이 음식 ㅈㄴ다네” “와 역시 킹종원 ㅠㅠㅠㅠ 너무 맛있어요” 처럼 현재 솔루션에 따라 디자인패턴이 만능의 해결방법은 아니니 적당히 사용하자.
덤) 백1종원씨는 웨 금지 단어노;;
개발자 농가 살려야쥬~
단일책임 말고 몰빵책임으로하면 간단하지 않을까요?!!
나여! 코딩종원
자동으로 행동하는 npc에 이동공격 따로 만들어도 상호작용이 되나
네 코드의 구조를 변경하는거기 때문에 class마다의 통신을 고려해서 구현하면 됩니다 - dc App
좋은글인데..이걸사실 유지보수를 실제로 해보고. 기획변경을 여러번 겪어보고. 경험으로 필요성을 느껴야 아는듯. ㅎㅎ
나도 이 사람 의견에 동의함. 개발자도 단계가 있다 생각함. 비효율적인 떡코드가 아이디어에 집중할수있어서 진짜 단기적으로 좋거든? 자기 혼자 넣고 싶은 걸 다 넣고 다 하다가 그 때서야 중요성을 알고 잘 볼수있다 생각함. 아무리 좋은 말도 자기가 필요성 못느끼면 안하고 흥미만 잃는다 생각함
맞음 직접 대가리깨지면서 필요성을 느끼는게 중요한듯 - dc App
예전에 함수랑 if 만 사용해서 게임을 만들던 시절이 생각나는군 ㅎ
이건 스파게티 코드 상태에서 기능 추가하고 변경하려고 발악하다 대가리 확실하게 깨져본 경험이 있어야 와닿는 내용인듯