개발 반성회

11/04
아마 이날 그동안 바빠서 그냥 지나치던 것들을 다같이 모여서 회고? 같이 했던 날인듯.
 
 

개발 비용 문제

예시로는 RichText와 RichLabel의 차이를 들었다.
RichLabel만 써도 충분한 곳에 RichText들이 남용되고 있다는 것. 색 변화 기능 하나만을 위해서 사용하고 있다거나...
RichText는 <Tag> 로 기능을 추가할 수 있도록 되어 있어서, <B> <T> <img> <font> <size> 등 tag를 기준으로 내부에서 파싱된 Label집합.. 의 형태라고 할 수 있다. 그렇기 때문에 목적에 따라, RichLabel에 바인딩된 함수로도 충분할 수 있는 것. 예시는 텍스트 표기를 위한 방법이지만, 이런 사소해보이는 구조 선정 하나하나도 신경쓰면 좋다는 내용.
또 다른 예시로는, RenderTexture 와 Spine 의 비교. 생각해보면 Drawcall을 줄이기 
>> 개발 단계에서의 비용에 대해 항상 생각해볼 것.
그래도 이 부분은 어느 정도 항상 고려하려고 하는 부분이었다. 문제는... 경험 부족으로 더 나은 비용이 무엇일지 한번에 떠오르지 않는다는것... 참고하려고 구조를 복붙하는 경우에도 이미 그 구조가 비효율적인 경우도 있었다ㅋㅋㅋ
개발 시간 문제도 있으니 항상 경계하되, 빠르게 개발해놓고 나중에 리팩토링 하는 방향이 제일 낫지 않을까 생각. 하지만 리팩토링을 할 턴이 잘 오지 않는 것이 함정이다(?)
 

코드 작성 기조 문제

기존 코드에 추가 작업을 할 때, 기존 작업자의 기조를 유지해야 한다.
뭐 어떻게 보면 당연하다고 할 수 있는 내용이지만, 자세하게 들어가면
일단 작업하려는 한 곳이 동작 된다고 다른 곳들의 동작을 고려하지 않으면, 한 가지 경우에만 대응되고 나머지는 다 박살날 수도 있다는 것.
작성자의 의도를 파악하고, 그 기조가 유지될 수 있는 방향으로 작성되는 것이 베스트이다.
방향성의 변경으로 이제는 진짜 사용하지 않아도 되는 것 같은 것들이 남아 있다면, 작성자 확인 후 제거할 것.
>> 의문이 가는 것이 있으면 전 작성자와 상의할 것.
뭐 이미 안 계신 분이라면 어쩔 수 없지만서도.. 그냥 봐서는 왜 이렇게 된거지??? 하는 것들도 다 뭔가의 히스토리 때문에 존재하더라... 는 것이 경험으로 얻은 것ㅋㅋㅋ 현재는 코드 변경 공유 채널이 있어 거기서 문의하거나 확인하거나 하는 식으로 반영중이다.
 

기획과의 조정 문제

요청 받은 것들을 할 수 있을 것 같다고 다 받으면 안 된다.
아무래도 개발은, 그리고 특히 게임 개발은 항상 뭔가가 추가되거나 수정되거나 없어지거나 한다. 그것이 이미 작업 완료된 것일 수도 있고, 새로 작업하려는 내용일 수도 있고, 작업 도중인 경우도 있으니...
사실 프로그래머로서는 안 되는 것은 생각보다 별로 없다. 다만 동작/정책이 확실하게 잡혀 있는가? 가 중요할 뿐... 그래서 이런저런 요청들을 말 그대로 '할 수 있으니' 받아들이게 되는데, 이런저런 난입 요청들을 다 받아서 합쳐놓으면 생각보다 시간 소요가 꽤 된다. 이런저런 핑퐁하다보면 거기에 드는 시간에.. 웃기지만 생각보다 스위칭 비용도 있고.. 해서
>> 비용을 산정해서 이 정도 걸릴 것 같은데, 기획에도 이 정도면 되는지 재 파악 요청을 해서 확인해야 한다.
돌려보내는 편이 좋긴 하다(?). 사실 난입 없어도 할 것들은 넘치기 때문... 그래도 무조건 안 된다고 하는 것이 아니라, 무조건 된다고 하지 말라는 것이 맞다.
 

기타

성장 방향성으로는, 여러 가지를 경험 해 가면서 나의 범위, 내 영역을 넓혀 가는 것은 중요하지만, 그 중에 흥미있었던 것들을 더 깊게 파서 깊이를 가져가는 분야가 있어야 한다는 것.
>> T자형 인재.. 가 되어야 한다.
웃긴건 글을 작성하면서 찾아보니 요새는 T를 넘어 파이, 빗?형까지 노려야 하는 것들이 점점 많아지는중ㅋㅋㅋ 아직도 길은 멀고도 험하다