[231025] 팀과제 역할 분담 및 수행, SOLID

• 팀 과제

오늘은 팀 과제 회의를 하면서 모두 공유할 코드의 큰 틀을 정하고 역할 분담을 했다.

 

코드의 틀은 패키지를 data, domain, service, io로 나누었다.

- data에는 database와 같은 역할을 하는 클래스를 저장한다. 주로 domain의 객체들의 집합을 저장하였다.

추가로 객체 리스트를 저장하는 장바구니가 있다. 또한 데이터베이스 내에서 처리할 수 있는 메소드를 포함한다.

- domain에는 이번 Hotel 프로젝트에서 정의된 클래스인 customer, reservation, room이 있다..

- service에는 서로다른 클래스의 메소드가 영향을 주고 받는 메소드를 포함된다.

- io에는 입출력에 관련이 있는 메소드를 저장한다.

 

그 외로 어느 패키지에도 포함되지 않는 Hotelmain 클래스의 메인 메소드가 HotelLounge 클래스의 메소드를 호출하고 주요 흐름은 HotelLounge에서 진행된다.

 

역할 분담은

1. 회원관리+로그인+관리자화면+마이페이지

2. 객실 목록 조회 및 예약

3. 장바구니 목록 조회와 취소 및 예약 확정

4. 고객의 확정 예약 조회 및 취소

이렇게 나누었고 나는 장바구니 목록 조회, 취소, 예약 확정 부분을 맡게 되었다.

 

• 팀 과제의 개인 역할 수행 소감

클래스의 단일 책임 원칙을 지키기 위해 클래스를 각 용도별로 나누기위해 노력했다.

팀원 분이 공유해주신 방식데로 데이터베이스, 주 객체, 서비스, 입출력 등으로 클래스들을 나누어 설계를 하니까 오히려 더 직관적이고 코드를 짜기 편하면서 재미있었던 것 같다. 그러다 보니 저번부터 듣게된 mvc 패턴이나 디자인패턴에 대해 더 알아보고 싶다는 생각이 들었다.

그리고 팀원분들께서 정말 많이 알려주셔서 객체지향적인 코드를 하는 방법에 대해 많이 배웠고 실력도 많이 늘 수 있었다.

처음으로 팀 협업을 하면서 여러 브랜치를 써보고 PR도 올려보았는데 처음이라 어색하기도 했지만 정말 재미있었다.

그리고 각자 역할을 나눠서 하다보니 코드를 실행시켜가면서 확인해볼 수 없어서 그 점이 조금 어려웠던 것 같다. 아직 테스트를 하는 방법은 잘 모르겠다. 그리고 코드를 모두 합치고 난 뒤 흐름을 만드는 것은 어떻게 협업할 수 있을지 잘 모르겠다.

이번 팀 과제를 통해 코드 리뷰와 협업 등을 통해 정말 많이 배우는 시간이 되었고 앞으로도 될 것 같다는 생각이 든다. 이번 팀 프로젝트가 팀원분들 모두가 만족할만한 결과물이 나왔으면 좋겠다.

 

• 배운 것
  1. 테스트 코드 등을 작성할 때 MVN repositoy 사이트에서 사용할 라이브러리가 있다면 이를 복사해서 build.gradle의 dependencies { . . . } 내부에 붙여넣기 한다.
  2. git stash로 commit을 하기 전에 브랜치를 옮기고 싶을 때 임시저장하여 현재 상태를 저장해두고 나중에 다시 기존의 브랜치로 돌아와 git stash apply로 다시 불러오기를 할 수 있다.
  3. intelliJ에서 alt+insert 키로 생성자/getter/setter 등을 불러올 수 있다.
  4. 예외처리를 해도 프로그램을 계속하고 싶을 때: input 클래스의 input을 받는 메소드에서 while문을 사용하여 무한반복 -> try-catch문으로 try에서 예외가 발생하면 catch문 실행 후 다시 try문에서 input을 받음. 예외가 발생하지 않으면 해당 input을 return하여 빠져나옴.
  5. 첫 PR 수행: 깃 컨벤션에 맞춰 Feat: basket으로 커밋 메세지로 커밋한 후 PR을 올렸고 팀원분들의 피드백을 받았다.
     • 클래스명이나 메소드명의 규칙(클래스는 대문자로, 메소드는 동사로 시작, 카멜 케이스 등)에 대해 다시금 되새겼다.
     • 피드백을 받은 코드를 수정 후 다시 push하는 경우의 커밋 메세지는 Refactor: 으로 표시하는 것도 알게 되었다.
     • setter로 값을 받아 대입하는 메소드를 사용하는 경우가 있고 값을 바꾸고자 하는 방향으로 메소드를 새로 만들어 사용하는 방식이 있는데 각 방식의 장단점이 있다는 것도 팀원분께서 설명해주셨다.

---

SOLID (객체 지향 설계 원칙)

객체 지향적으로 설계하기 위해 SOLID 라 불리는 다섯 가지 원칙이 있다.

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

• 하나의 클래스는 단 하나의 책임만 가져야 한다.
• 단일 책임 원칙을 지키지 않을 경우 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있다.

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

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 기능을 변경하거나 확장할 수 있으면서 기능을 사용하는 코드는 수정하지 않는다.

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

• 프로그램 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

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

• 범용 인터페이스 하나보다 클라이언트를 위한 여러 개의 인터페이스로 구성하는 것이 좋다.
• 인터페이스는 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
• 클라이언트가 필요로 하는 인터페이스로 분리함으로써 각 클라이언트가 사용하지 않는 인터페이스에 변경이 있어도 영향을 받지 않도록 만들어야 한다.

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

• 추상화에 의존해야지 구체화에 의존하면 안된다.
• 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안되고 저수준 모듈은 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.