오늘 대망의 발표가 있었다. 다들 좋게 봐주신 거 같아서 다행이다.
튜터님의 자세한 서면 피드백은 내일 받을 수 있다고 하고, 오늘은 발표 직후에 튜터님들이 간단하게 대면으로 피드백 해주셨다.
우리 팀에 대한 피드백 뿐만 아니라 다른 팀의 피드백도 나한테 많은 도움이 됐다. 내가 겪은 문제들을 다른 팀들도 겪고 있었기 때문인 것 같다.
튜터님들이 말하시길 이번 팀 프로젝트의 의의는 크게 두 가지라고 하셨다.
첫 번째는 Git 사용을 통한 협업에 익숙해지기.
두 번째는 객체 지향적인 코드를 짜기.
나도 객체 지향적인 코드를 짜는게 정말 중요한 프로젝트였다고 생각한다.
과제에서 요구하는 요구사항이 캐릭터, 아이템, 인벤토리, 상점, 던전, 몬스터 등등 게임에서 클래스하면 떠오를 만한 내용들이었다.
이건 다른 팀의 피드백 중에 나온 내용인데, 내 얘기인 것 같아서 가슴에 비수처럼 꽂혔다.
캐릭터, 아이템, 인벤토리 등등 위에서 나온 자기의 역할이 명확한 것들은 다들 클래스로 잘 짜셨다고 하는데, 문제는 게임의 로직, 전투의 진행, 화면에 그리기 등등 추상적인 부분들은 다들 Main 메서드에서 처리하려고 하셨다고 한다.
이거 너무 내 얘기 같았다. 팀 프로젝트 진행 전 개인 과제 때, 나도 캐릭터, 인벤토리, 상점등은 클래스를 이용해서 객체 지향적으로 잘 짰다고 생각했는데, 씬을 그리고 씬의 로직을 처리하는 부분을 모두 Main 함수가 있는 Program.cs
파일에서 메서드를 하나하나 만들어가면서 작성했고, 수백 줄이 달하는 코드가 한 파일 안에 있게 됐다.
수 십개의 메서드들이 서로 다른 역할을 하고 있고, 게임의 로직도, 화면에 그리는 역할도 한 번에 수행하고, 씬 구분을 switch 문으로 해놓고 씬 마다 스텝을 만들겠다고 switch 문 안에 switch문을 또 쓰고... 당시에도 튜터님께서 리팩토링을 진행해보는게 좋을 것 같다고 피드백해주셨는데 지금 생각해보면 정말 엉망으로 짰던 것 같다.
이번에 정말 팀원 분들을 잘 만난게, 저런 추상적인 부분들도 클래스로 잘 짜주셨다.
화면에 문자를 출력하는 걸 총괄하는 Renderer
클래스.
게임의 진행을 담당하는 전역 객체인 Game
클래스.
씬의 동작 방식을 명확하게 제시해주는 Scene
클래스와, 이걸 관리하는 SceneManager
클래스.
또 각 선택지들을 구현하는 ActionOption
클래스까지.
추상적인 객체들도 역할을 잘 분리해서 클래스로 짜주셨다.
덕분에 이 클래스들을 이용해서 구현한 씬을 복붙하면 그럴싸한 씬이 또 나온다.
역할을 잘 구분해서 클래스화 해놓는 것만으로도 코드의 재사용성이 얼마나 올라가고, 가독성과 작업의 편의성에서도 얼마나 쾌적해지는지 정말 많이 느꼈다.
팀 프로젝트를 시작할 때, 나는 인벤토리의 구현을 맡았다. 각자 진행했던 개인 과제에서 좋았던 부분을 한 분씩 맡아서 구현하기로 했었다.
첫 날 회의에서 위의 Renderer
와 Scene
클래스들을 보니까 나도 저런식으로 짜봐야지!! 라는 생각이 들었다.
마침 그떄 들은 강의에서도 delegate와 lambda 등의 개념이 나왔어서 적극적으로 이용해본 것 같다.
아이템 - 인벤토리 - 상점의 구조를 담당하다보니, 서로 유기적으로 상호작용하면서도 의존성은 크지 않게 설계하기 위해 노력했다.
서로에 대한 참조는 최소한으로 줄이고, 필요한 경우에만 매개변수로 받아와서 사용하도록 했다.
그 과정에서 delegate와 lambda가 정말 많이 도움 된 것 같다.
일주일 밖에 안되는 아주 짧은 기간의 프로젝트였지만, 정말 많이 배웠다.
객체지향, 의존성 이런거를 생각하며 구현을 하면서도 한 편으로는 사용자의 입장에서도 많이 고민하며 코드를 짰던 것 같다.
상점을 이용할 때 끼고 있는 아이템을 팔면 자동으로 장비 해제도 진행된다던가... (이 부분을 event로 구현해서 특별한 예외처리 없이도 구현할 수 있었다.) 좌우 방향키 딸깍딸깍으로 상점의 구매/판매 화면을 자유롭게 넘나든다던지...
이외에도 화면에 보여지는 정보들을 사용자가 어떻게 받아들일지 고민해서 작업을 했던 것 같다.