[2주차] 2023-06-08

Last updated - 2023년 06월 09일 Edit Source

2주차 DAY 04.. 본격적인 계산기 과제를 시작했다. 계속 설계에만 몰두하다보니 정작 코드는 많이 짜지 못하였고, 금일 RBF나 잡혀있어서 생각보다 이래저래 시간을 많이 썼다.

RBF (Random Bit Filp) 시간 때 팀원분께서 인텔리제이 플러그인인 Translation을 알려주셨다. 평소 변수명을 짓기 위하여 구글 번역기를 전전하던 나로써는 너무나 큰 꿀팁이었다.

플러그인 설치 이후 명령어는 아래와 같다.

• ctrl + cmd + i : 번역기 팝업 띄우기
• ctrl + cmd + u : 영어 → 한글 번역 (docs 볼 때 유리)
• ctrl + cmd + o : 한글 → 영어 번역 (변수명 짓기 개꿀)

설계에 관한 고민만 하다가, 본격적으로 코드를 많이 짜지는 못한 상황이다.

• Operator 인터페이스를 구현하는 Addition, Substraction, Multiplication, Division은 너무 과한 것 아닐까? 세부적으로 구현되는 코드도 별로 없을 것이고.. 책임을 “연산"으로만 나누고 “덧셈"과 같이 구체적으로 나눠야하나?
  • enum으로 따로 빼서 함수형 인터페이스를 사용하면 어떨까
• Integer 사용 시, 계산 결과가 21억까지 밖에 나오지 않을텐데, 예외 처리를 하는 것보다 더 큰 수를 다룰 수 있도록 하는 것이 낫지 않을까
  • BigDecimal을 사용하면 어떨까
• 메뉴 번호를 입력 받을 때 1번과 2번만 받아야하는데, 이를 따로 뺴야하나?
  • 이것 역시 enum으로 빼고 이외의 숫자나 문자가 들어오게 된다면 예외를 던져볼까
• 예외처리하는 클래스를 따로 만들어서 처리하는 것이 나을까
• Console을 통하여 입출력을 받는 상황인데, 나는 Input 인터페이스와 Output 인터페이스를 만들었고 이를 구현하는 InputView 클래스와 OutputView 클래스를 만든 상황. 이걸로 충분할까?

위와 같은 고민만 하다가 정작 코드는 많이 못 짠 상황인데, 팀 미팅 시간에 다른 팀원분은 진행이 어느정도 된 상태라 흑구 멘토님이 간단하게 리뷰해주셨다. 그 과정에서 자연스레 나의 고민도 약간이나마 해결되었다.

1. 연산이라는 책임만 지게 하는 것이 괜찮다. 객체지향적으로 설계하다보면, 파일이 너무 많아지는 것도 있고, 사칙연산 하나하나를 클래스로 빼게 되는 것은 좋지 않아 보인다. enum으로 빼보자. (내가 고민하던 방향으로 해결 🟢)
2. calculate(int, int) 같은 경우 테스트 코드를 짰을 때 문제가 생길 것 같지 않을까? 역시 내가 고민하던 방향이 맞았다. BigDecimal을 사용해보자.
3. 메뉴 번호 처리 역시 enum으로 빼는 방향이 맞았다.
4. 예외 처리하는 클래스를 따로 만드는 것 까지는 해결되지 않았지만, 최대한 자바스럽게 코드를 짜보자. try-catch나 throw와 같이 예외처리를 반드시 해보는 쪽으로! 코드가 더러워지는건 같이 고민해주겠다.
5. if - else if 에 관하여 생각해본적이 있는가. if는 분기처리를 하여 쭈루룩 다 돌아야하기도 하고 가독성도 그렇게 좋지는 않다. switch 문을 고려하자. 흑구님의 Java Switch문 정리하기 게시글을 참고하자.
6. Input, InputImpl, Output, OutputImpl, Console이 있고 상속의 형태가 아닌 컴포지션을 이용해보는 것은 어떠한가 (디자인 패턴의 컴포지트 패턴 ❌)
7. Calculator에서 repository를 다룰 필요가 있나? 또, Calculator가 맡는 역할이 너무 많지 않은가?
   • 계산기의 책임이 연산의 책임이라고 생각할 필요가 없을 것 같다.
   • 계산기, 연산, 표현식과 같이 3가지 책임으로 생각해보는 것은 어떨까
8. 시스템이 거대해졌을 경우도 생각해보자.
   • Main 메서드에서 ManagementSystem과 같이 시스템을 만들고 의존성을 주입해보는 방식

우선, 기억 나는대로 다른 팀원분이 받은 피드백을 정리해봤는데, 사실 이해가 가지 않는 부분도 많았다. 이 부분은 내일 추가로 질문드릴 예정이다.

pre 팀 첫 미팅 때 나왔던 피드백과 사실 결이 비슷했다. 받은 피드백을 토대로, 앞으로 어떤식으로 바꿔가야할 지 목록은 아래와 같다.

• 하나를 깊게 파는 것이 너무 중요하지만, 사실 데브코스 기간 동안은 잠시 내려 놓자. 가성비가 굉장히 떨어지는 방식이다. 결국 목적은 취업이니까.
• 설계라던가 꼼꼼함이라던가는 조금 내려놓자. 특히, TIL 작성, 수업 필기 등 코드 짜는 것이나 외적인 요소에 너무 신경쓴다. 제발 설계는 간단히, 필기는 간단히하고 코드부터 짜기, 머리로 이해하며 기억하기를 추구하자
• 데브코스 과정은 생각보다 어렵고 빡센 과정이다. 올빼미형으로 살다가는 버티기 힘들 수 있다. 생활 패턴을 아침형으로 바꿔보자.