스크립트를 짜는 팁

 

 하나의 함수는 하나의 기능을 하도록 하고 그 하나의 기능들이 묶어지면 클래스로 꺼낸다. 보통 코드를 계속 짜다가 이거는 하나에 완결된 형태로 꺼낼수 있다고 느껴지면 밖으로 따로 클래스로 꺼낸다. 

 이렇게 꺼내였을때 꺼낸 부분을 대부분 프라이빗으로 은패를 하고 함수를 들어가는 입구 정도만 파블릭으로 선언해서 마치 이 코드가 유니티에서 제공하는 기본 함수처럼 느껴지도록 코딩을 한다. 인풋이 들어가면 아웃풋이 나오는 형태가 되곤 한다.

 계속 확장되어 가는 영역이 있고 이미 완결된 부분은 각각이 따로 분리가 되는 방식이다. 

 짧은 코드로 보여주기는 쉽지 않아서 자세한건 실전에서 알려주면서 해야 할듯 싶다. 이런 방식을 적용하다 보니 처음부터 설계를 짤 필요가 없다. 이 원칙을 따라 코딩을 하면 자연스럽게 처음부터 설계를 짠거처럼 구조화 된다. 

 수시로 리펙토링이 들어가게 된다. 요약하자면 설계보다는 리펙토링에 더 힘을 실는다고 보면 된다. 내가 코드를 간결하게 짜는 리팩토링 능력이 뛰어나기 때문에 이 장점을 살리는 전락이다. 

 면접 들어가면 리펙토링 능력이 좋고 코드를 간결하게 짠다는 이야기는 꽤나 많이 듣는 편이다. 이력서에 깃헙 코드를 공개한 이후로는 거이 이 이야기는 면접때 마다 빠지지 않는듯 싶다.

 그리고 스타트나 메인같은 함수에는 함수를 호출하는 것만 넣어서 마치 논문에 초록처럼 활용한다. 스타트 부분만 읽어도 이 클래스가 무엇을 하는지 파악할수 있도록 짠다. 

 업데이트의 경우에는 카메라 이동 같은거나 키보드 인풋 같은거만 주로 활용하고 나머지는 주로 코루틴을 활용한다. 코루틴의 경우에는 제어가 쉽다는 장점이 있기 때문이다. 

 어웨이크에는 이 클래스가 어떤 클래스와 연결이 되어 의존관계가 생기는지 보여주기 위해 일부러 파인드 오브젝트 타입을 쓰는 편이다. 팀원들에 실력이 뛰어나서 믿고 맡길수 있다면 스타틱을 써서 연결할수도 있는데 그 경우에는 의존성이 어떻게 발생하는지 파악하기가 쉽지 않기때문에 잘 사용하지 않는다. 일부로 보여주는 거다. 

 손으로 스크립트나 오브젝트를 이어서 붙이지는 않는다. 가끔 떨어지기도 하기 때문이다. 그거 떨어지는 거 붙이는게 은근히 짜증난다. 

  https://github.com/aigoia/goetita

GitHub - aigoia/goetita: the first game project

 여기 내 코드가 공개가 되어 있는게 있는데 아마 보면 어떤 느낌인지 알듯 싶다. 이것도 한번 대규모 리팩토링을 하기 전이라. 지금코드는 이거보다 더 깔끔하게 구성이 되어 있다.