2024년 5월 23일 목요일 개발일지 / 팀 프로젝트 발표와 회고, SOLID 원칙에 대해서

Modlist 2024. 5. 23. 21:07

2024년 5월 23일 목요일

프로젝트 제출과 발표 준비

오늘은 프로젝트 제출과 발표가 있는 날이기 때문에 오전에는 발표자료와 대본을 만들었습니다. 오전 분반별 콘텐츠가 끝나고 팀원분들이랑 바로 회의를 통해서 코드 리펙토링과 주석처리, ReadME 재정리, 프로젝트 소스 코드 정리 등등 각자의 역할 분담을 통해 무사히 팀 프로젝트 제출을 완료했습니다.

저는 발표를 해야했기 때문에 아직 끝난 게 아니어서, 제출 한 뒤에도 발표 PPT 정리와 대본 정리를 더 하고, 몇 번 리허설을 하는 등 발표에 대비를 했습니다.

점심을 먹고 나서 대망의 발표를 할 시간이 왔습니다. 다른 조들에는 다들 능력자가 많으셔서 재미있고 다양한 게임들을 많이들 만들어주셨고, 저희 조 차례가 다가왔을 때, 저의 심장은 쉴 줄 모르는 듯 엄청 긴장하게 됐습니다. 그래도 처음에 준비를 했기 때문에 발표를 순탄하게 이어가던 도중 시연 영상을 틀었는데... 소리 공유가 안된 이슈가 있었습니다. 그렇게 좀 얼타다가 다시 해결하고 발표를 이어 나갔고, 무사히 발표를 마치게 됐습니다.

팀 프로젝트 간단한 회고

발표가 끝나고 나서 저희들은 간단한 회고를 진행했습니다. 저희가 처음부터 "잘할 수 있을까?", "완성 못하는 건 아니겠지?", "우리 노베이스인데 따라갈 수 있을까?" 등등 많은 생각도 들었고, 각종 이슈나 문제에 대해서 튜터님과 매니저님들의 도움을 통해서 해결해 나가고, 천천히 하나하나 계획을 세우면서 게임을 완성해 나간 것이 저희의 "티모 버섯 피하기"라는 결과로 나오게 되지 않았나 생각이 듭니다.

솔직히 저희 실력에 비하면 완성도 높게 나온 것 같지만, 시간이 좀 더 있었다면 가렌이라는 캐릭터 외에도 다른 캐릭터나 2인 플레이 모드, 다양한 연출 등등 좀 더 깔끔하게 완성도 높게 만들 수 있지 않았을까 생각이 드네요.

팀원분들이랑 서로 이번에 느꼈던 점이라든가, 아쉬웠던 점, 다른 조들의 프로젝트가 대단하다는 점 등등 다양하게 이야기를 하면서 저녁 먹기 전까지 많은 이야기를 나누었습니다. 내일이 되면 조가 바뀌기 때문에 서로 고생하셨고, 팀 이름이 롤대남인 만큼 마무리로 롤 한판 할 수 있으면 하기로 얘기를 하게 됐습니다.

SOLID 원칙에 대해서

저녁에는 이성언 튜터님께서 객체 지향 2부로 강의를 해주셨는데, 처음 부분에는 저번에 했던 의존도(결합도), 의존성 등등 을 복습하고, SOLID 원칙에 대해서 이야기를 해주셨습니다. 이에 대한 내용은 밑에 간단하게 남겨보겠습니다. SOLID 원칙 내용이 끝나고 실습 강의를 통해서 각종 원칙이나 원리를 이해하기 쉽게 설명해 주셨습니다. 그렇게 강의가 끝나고 나서는 다들 TIL 쓰고 오늘 하루를 마무리했습니다.

SOLID 원칙이란?

- 객체 지향 설계에서 좋은 코드를 작성하기 위한 다섯 가지 기본 원칙을 의미 한다.

- 이 원칙들은 소프트 웨어의 유연성, 유지 보수성, 확장성을 높이는 데 도움을 줍니다.

- SOLID는 다음과 같은 다섯 가지 원칙의 약어입니다.

1. 단일 책임 원칙 (Single Responsibility Principle, SRP)

- 클래스는 하나의 책임만 가져야 하며, 클래스는 그 책임을 완전히 캡슐화해야 한다는 원칙이다. 즉, 클래스는 하나의 기능을 수행하는 데 집중해야 하며, 변경의 이유가 오직 하나여야 한다.

2. 개방-폐쇄 원칙 (Open-Closed Principle, OCP)

- 소프트웨어 엔티티(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 원칙이다. 즉, 기존 코드를 수정하지 않고도 기능을 추가할 수 있어야 한다.

3. 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)

- 자식 클래스는 언제나 자신의 부모 클래스를 대체할 수 있어야 한다는 원칙이다. 즉, 자식 클래스는 부모 클래스에서 기대되는 동작을 모두 수행해야 한다.

4. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

- 하나의 일반적인 인터페이스보다 여러 개의 구체적인 인터페이스가 낫다는 원칙이다. 즉, 인터페이스는 특정 클라이언트를 위한 메서드들만 포함해야 하며, 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다.

5. 의존 관계 역전 원칙 (Dependency Inversion Principle, DIP)

- 고수준 모듈은 저수준 모듈에 의존해서는 안 되고, 둘 다 추상화된 인터페이스에 의존해야 한다는 원칙이다. 즉, 구체적인 구현이 아닌 추상화에 의존해야 한다.