[ 우아한 테크코스 ] 백엔드 우테코 프리코스 2주차 회고

⭐ [ 2주차 리뷰 ] 우당탕탕 2주차 생존기

1주차 때 부족한 부분들이 많았어서 객체지향 개념, 컨벤션 등 정리를 시작하고 2주차 코드를 구현했다. 노션에 정리를 해놨는데, 블로그에 올리기에는 글들이 깔끔하지 않아서, 보기 좋게 정리 한 후에 블로그에 올릴 생각이다..& 이번 2주차의 코드를 구현하면서 얻은 것들이 많은 것 같다. 알고만 있고, 중요하다고 생각한 객체지향의 개념에 대해서 공부하면서 코드를 구현하니, 계단을 오르면서 코드를 구현하는 느낌? 코드 완성이라는 목표를 향해서 차근차근 올라가는 느낌이라 너무 재밌었던 것 같다.

이번 주차때 제일 중요하게 생각했던 부분은 기능 분리, 가독성인 것 같다. 특히 메서드 하나에 많은 기능이 포함되어져 있는지를 중점으로 본것 같다. 특정 기능을 담당하는 메서드는 해당되는 클래스에 있어야 하는 것 같은데, 메서드가 늘어나면 클래스가 가지고 있는 부담이 커져서 유지 보수에 안좋은 영향을 끼치진 않을까 고민을 했다. 만약 메서드를 분리해야 한다면 새로운 클래스를 만들어야 할지 고민했는데, 너무 많은 클래스를 만들면 오히려 가독성이 떨어지진 않을까 고민했다. 아직 갈길이 많이 먼 것 같다.

 

 

[ 프리코스 2주차 PR ]

https://github.com/woowacourse-precourse/java-racingcar-7/pull/1102

 

📌 1주차 피드백을 보완 했는가 ?

❓ 1주차 피드백은 아래와 같다.

 

---

• 변수명, 메서드 이름, 클래스 이름 직관적으로 표현할 수 있는 이름(= 이름을 통해 의도를 드러낸다)
  • 변수명을 축약하지 않는다.
• 커밋 메시지 의미있게 작성
• 기능 분리
• 상수 선언
• 객체지향 생활체조 원칙 정리
• 배열 대신 컬렉션을 사용

 

 

 

📌 2주차 구현 회고 (피드백 적용)

❓ 2주차때 피드백을 적용하면서 느꼈던 점

---

기능을 분리 하자

요구사항의 기능을 수행하기 위해서는 여러가지의 메서드가 필요하고, 이 메서드들은 각자의 기능을 가지고 있다. 처음 1주차에서 기능을 구현할때 하나의 메서드에 여러가지 기능을 넣은 것에 대한 피드백을 많이 받았던 것 같다.

2주차에서는 큰 기능에 먼저 집중했다. 자동차 레이스를 하기 위한 기능을 만들기 위해서 입력으로 받은 이름을 분리하는 기능, 랜덤한 숫자로 자동차 끼리 경주하는 기능, 우승자를 출력하는 기능 등 큰 기능들이 존재한다.

어떻게 기능을 나눠야 할지 처음엔 감이 잡히지 않아서, 큰 기능들을 먼저 만들었다. 예를들어 입력으로 받은 이름을 분리하는 큰 메서드를 만든 후에 하나씩 빼서 작은 메서드로 나누는 방법으로 진행했다.

사실 이렇게 하면 효율적이지 않은것 같은 생각이 들었지만, 일단 시도는 해보고 고치자 라는 생각으로 쭉 만들었던 것 같다. 아무튼 큰 메서드를 만들고, 예외처리를 하고 그런식으로 작은 메서드로 분리했는데 분리하면 할수록 이 기능이 과연 이 클래스에 있는게 옳은가 ? 라는 생각이 들었다. 이때부터 아 처음 기능을 구현할때부터 뭔가 잘못됐구나 라는 생각이 들었다. 그럼 효율적으로 기능 분리를 어떻게 해야 할까 ? 라는 생각이 들어서 프로그램 완성 후에 기능 모델링에 대해서 찾아보았다.

기능 모델링에 대해서 찾아보는 중에 UML 클래스 다이어 그램을 발견하게 됐다. UML에서는 클래스명, 속성, 연산 3요소로 구성하고 클래스 간에 어떤 상관성이 있는지를 클래스의 관계로 나타낸다고 한다.

→ 일반 명사는 클래스로, 동사는 클래스의 연산으로, 고유 명사는 클래스의 인스턴스인 객체로, 형용사는 클래스의 속성으로 매핑

이번 3주차때는 UML다이어 그램 중 클래스 다이어그램을 작성해보려고 한다.

아무튼 기능을 분리하긴 했는데, 리뷰를 기다려야 할 것 같다.. 혼자서는 뭐가 잘못됐는지 알기가 조금 힘든 것 같다.

 

 

객체지향적 프로그래밍을 해보자

 

객체지향적 프로그래밍을 위해 SOLID 원칙을 지키는걸 목표로 해봤다. 그중 단일책임원칙( Single Responsibility Principle ) SRP 를 집중적으로 생각했다. 객체지향에서 기능분리는 프로그램 유지 보수, 가독성을 위해서는 중요하다고 생각한다. 기능 분리에 대해서는 위쪽에 충분한 설명을했고, SOLID 원칙에서 가장 어려웠던건 개방- 폐쇄 원칙( Open-Closed Principle) OCP 이었던 것 같다. 과연 사용자에게 어디까지 공개해야 할지, 보호해야할 정보는 무엇인지에 대해서 고민을 많이 했던 것 같다. 이번에 UML 다이어 그램을 짜면서 접근 제어자를 같이 설정하는게 좋을 것 같다는 생각이 드는데, 과연 내가 이걸 꼼꼼히 잘 할 수 있을까 ? 라는 생각이든다.. 근데 !! 해봐야지!!!

객체 지향 프로그래밍이란 과연 무엇일까? 아직 어느 부분을 지켜야 좋은 코드인지, 프로그램 흐름을 따라가기 어렵다는 생각이 든다. 부족한 부분이 점점 보이는 것 같고 성장은 하고 있는 것 같은데 조금 조바심이 든다!!

원칙 몇가지를 정해서 그 몇가지만은 꼭 지키도록 해보는건 어떨까? 한번에 많은걸 할수록 놓치는게 더 많은걸 이번 2주차에서 느낀 것 같다. 3주차에서는 코드를 구현하기전 나만의 몇가지 규칙을 정해야 할 것 같다. 3주차의 나의 회고가 기대된다. 과연 얼마나 성장해 있을까 ?

 

 

상수 선언을 사용해보자

 

리뷰에서 상수 선언의 중요성에 대해서 알게 되었다. 프로그램 확장 과 유지보수에는 필수라고 생각이 들었다. 이번 2주차 자동차 경주 게임에서 상수 선언이 필요한 부분은 자동차 이름 구분을 위한 쉼표, 무작위 값 범위, 전진 조건, 출력 할때 구분 자 등이 있었다. 사실 무작위 값들은 하나의 상수에 선언하는게 맞다고 생각이 드는데 고민이 들었던건 구분자였던 쉼표 였다. 이 구분자 쉼표 상수 클래스를 생성해서 선언을 할지 아니면 해당 상수가 쓰이는 비지니스 로직에 상수를 둬서 바꿀 수 있게 할지 고민이 됐다. 지금은 데이터 하나(=쉼표) 여서 상수로 따로 클래스를 만들기 보다는 비지니스 로직 부분에 상수로 선언해주는 것도 나쁘지 않을 것 같은데 뭐가 맞는지 모르겠다..

이 문제에 대해서는 3주차 과제를 진행하면서 천천히 찾아볼 예정이다. 3주차 회고에서는 답을 찾았으면 좋겠다 !

 

 

 

📌 2주차 피드백

---

• 기능을 분리하는 기준
• 테스트 코드를 작성하는 법
• README 보완
  • 예외코드 직관적 설명
  • 기능, 클래스 설명 자세히 할 수 있게