[TIL] 2025-04-30 알고리즘 문제, SOLID, 모의 면접, 프로젝트 장르 선정, 깃 전략, 디렉토리 구조
2025-04-30 TIL
알고리즘 문제
이번 문제는 설명 자체로는 이해하기가 좀 어렵게 느껴졌는데, 예시를 보고 잘 이해를 했습니다.
그런데 문제를 어떻게 풀어내야할지 쉽게 아이디어가 떠오르지 않아 어떤 자료구조를 사용해야할지 어떤 알고리즘이 필요한지 고민을 많이 해보았습니다.
결국 어떻게 풀어내야할지 찾지 못해서 아이디어만 살펴보았고, 구현은 직접 해보았습니다.
그리디 알고리즘 문제였는데, 이전에도 그리디 알고리즘 문제에서도 어려움을 느꼈던 것 경험이 있던걸 생각해보면 그리디 알고리즘 문제를 잘 풀어내지 못하는 것 같습니다.
[프로그래머스][C++] 요격 시스템
SOLID
디자인 패턴을 학습하면서나 프로젝트를 진행하면서 객체지향 프로그래밍이라는 단어를 많이 듣고, SOLID라는 것을 잘 지켜야한다.
대략적으로 어떤 개념이다라는거를 찾아보고 이해만 하고있었는데, 오늘 직접 살펴보고 정리해보았습니다.
이제 정확하게 어떤 원칙들이 있고, 각 원칙들을 위해 어떻게 해주어야 하는지 이해한 것 같습니다.
잊더라도 다시 살펴보아 금방 기억해낼 수 있도록 정리해보았습니다.
객체지향 프로그래밍 제 5원칙 SOLID
모의 면접
모의 면접을 한번 보았습니다.
면접에서 아직 부족한 부분도 있고, 조금씩 나아지는 부분도 있고, 잘하는 부분도 있는 것 같습니다.
우선 기술적인 질문에 대한 답변에 대답을 깔끔하게 하지 못하고, 전문적인 느낌을 주지못한다는 문제가 있는 것 같습니다.
이 문제는 스파르타 내배캠에서 학습한 내용들을 제대로 복습하지 못하고 커리큘럼을 따라가고만 있다보니 학습했던 내용을 대답하긴 하지만, 제대로 핵심만 짚어서 질문의 의도로 키워드를 깔끔하게 대답하지 못하기 때문이라고 생각합니다.
이를 해결하기위해 파편화된 지식을 술술 나올 정도로 잘 기억해두는게 좋을 것 같습니다.
말하는 소프트 스킬 자체에서 부족한 것은 아니기 때문에 제가 뭘 정확하게 알고있고, 모르는지를 분석해보아 학습해보는 방법이 좋을 것 같습니다.
다른 문제로는 제가 프로젝트를 진행하면서 가지고있는 좋은 경험들 예를 들어, 팀장을 맡아서 팀원들의 작업을 분배하고, 잘 따라오지 못하는 팀원들에 대해 어떻게 대응했는지, 디버깅이나 트러블 슈팅에 대해서 어떻게 했는지 등을 이번 모의 면접에서 어필해내지 못했는데, 잘 어필해내는게 좋을 것 같습니다.
마지막으로는 클라이언트 프로그래머를 시작하게된 동기에 대해서 조리있게 잘 말해내지 못했습니다.
이 문제는 제가 실제 시작하게되 동기에 대해 생각을 정리해서 말만 부드럽게 잘 할 수 있으면 된다고 생각합니다.
저의 동기는 원래 요리를 본업으로 했었는데, 맛있는 음식을 제공했을 때 누군가가 이 결과물을 좋아해주고, 즐겨준다는 것에 뿌듯함과 행복감을 느꼈었습니다.
그런데 마인크래프트라는 게임에서 플러그인으로 컨텐츠를 추가해볼 수 있는 기회가 있었고, 이 컨텐츠들을 훨씬 더 많은 인원이 좋아해주고 즐겨준다는 것에 큰 행복감과 즐거움을 느꼈기 때문에 클라이언트 프로그래머를 시작하게 됐었습니다.
이 내용을 잘 정리해서 면접 때 얘기한다면, 동기에 대해서도 잘 설명할 수 있고 전공과 다른 분야를 선택한 것도 설명된다고 생각합니다.
이렇게 모의 면접을 통해 부족한 부분을 보완할 수 있는 좋은 계기가 됐고, 제가 모의 면접에서 어필할 수 있는 부분들에 대해서 살펴보았습니다.
앞으로도 부족한 부분은 보완하고 저의 강점은 더 특별한 강점으로서 만들어내면 좋겠습니다.
화이팅!!!
프로젝트 장르 선정, 깃 전략, 디렉토리 구조
오늘 최종 프로젝트 팀에서 회의를 진행했습니다.
프로젝트의 장르를 선정해주어야 했는데 팀원들이 모두 원하는 게임의 장르가 달라서 의견을 정리하고, 모두가 어느정도씩 수용할 수 있도록 중재를 했습니다.
기존에는 FPS, RPG, 소울라이크, 레이싱, 로그라이크, 시뮬레이션, 시나리오, 퍼즐 등 다양한 장르에 대해 요청이 있었습니다.
너무 다양한 장르기 때문에 팀원들이 취업을 목적으로 한다는 공통점으로 마이너한 장르를 제외하여 팀원들이 수용할 수 있는 이유로 특정 장르를 제외하였습니다.
또한 팀원들과 비밀 투표로 선호도가 높은 장르를 선택하여 결과적으로 FPS, RPG, 로그라이크가 선정되었습니다.
여기에서 이제 팀원들의 의사를 반영하여 장르들을 어느정도 섞어서 진행하기로 했습니다.
결과적으로 일부 팀원들이 원하는 장르를 선택하지 못하기도 했지만 수용할수 있는 근거 및 합리적인 과정과 절충안으로 트러블 없이 장르를 잘 선정해냈습니다.
깃 전략에 대한 회의 결과는 다음과 같습니다.
Rebase를 사용하기로 했습니다.- 브렌치는 라이브 버전, 개발 버전, 개발 버전에서 분리된 브랜치인 기능 구현과 버그 수정, 라이브 버전의 핫픽스 등 브렌치를 목적과 기능에 따라 분리하고 작업하도록 약속 했습니다.
- 풀 리퀘스트는 적극적으로 사용하며, 하루 단위나 특정 기간 단위가 아닌 기능 단위로 커밋하여 풀 리퀘스트 하기로 약속했습니다.
- 이때 풀 리퀘스트를 승인하는 사람은 팀장인 저와 부팀장이 확인하여 승인하기로 결정했습니다.
회의 끝에 언리얼 엔진의 디렉토리 구조는 다음과 같이 결정했습니다.
Content폴더에서 애셋들 즉, 리소스들은 Asset이라는 폴더에서 카테고리 별로 분류하기로 했습니다.
이 방법으로 팹에서 어떤 종류의 애셋들을 임포트해도 분류만 잘 해준다면 특정 애셋을 찾기에 용이할 것이라고 판단됩니다.
다음으로 블루프린트 클래스들은 부모 클래스 단위로 분류해주었습니다.
이 방법을 사용한 이유는 사용에 있어서 목적이 다양한 클래스를 분리하기 쉽게 함이 있습니다.
예를 들어, 플레이어 캐릭터가 사용하는 애니메이션 인스턴스가 있는데, 이 애니메이션 인스턴스를 AI가 사용하게 된 경우 블루프린트 클래스를 사용하는 목적이나 주제로서 분류를 했었다면 플레이어 폴더, AI 폴더, 별도의 폴더 등 블루프린트 클래스를 어디에 두어야할지 애매할 수 있는 문제를 미리 예방할 수 있다고 생각합니다.
또한 폴더의 구조가 복잡해지거나 난해해지지 않기 때문에 클래스를 찾아가는 과정 또한 어렵지 않을 것이라 생각합니다.
C++소스 및 헤더 파일의 접근제어자나 폴더 구조에 대해 회의가 있었는데, 이 경우 다음과 같습니다.
C++파일을 생성할 경우 접근제어자를 지정해주지 않고 생성하여 Public과 Private를 분리하지 않고, 클래스별로 폴더를 분리하기로 했습니다.
이 경우 폴더로 분리했기 때문에 헤더파일을 인클루드 할 때 좀 더 간편하고 효율적으로하기 위해서 PublicIncludePaths.AddRange를 사용하기로 했습니다.
이 경우에도 C++파일을 찾을 경우 좀 더 짧은 시간에 효율적으로 찾기 위해서 선택한 방법입니다.
이렇게 프로젝트에 대해서 회의를 진행해 보았는데, 아직까지 팀원들이 잘 따라주고, 트러블이 없다는 것에 만족감을 느낍니다.
앞으로 해결해야할 사항들이 많은데 모든 팀원들과 함께 끝까지 잘 마치고 싶습니다.
댓글남기기