https://github.com/woowacourse-precourse/java-calculator-7/pull/275
[문자열 덧셈 계산기] 최인호 과제 제출합니다. by inhooo00 · Pull Request #275 · woowacourse-precourse/java-ca
java-calculator-precourse 구현할 기능 목록 입력 게임 시작 메시지 출력 문자열 입력 출력 덧셈 결과 출력 기능 "//"와 "\n" 사이에 위치하는 문자를 커스텀 구분자로 설정 구분자 기준으로 문자열 분리
github.com
일주일이라는 시간이 굉장히 빠르게 지나갔네요..
시험 공부하랴 프리코스하랴 정신 없었던 주였습니다. 항상 시험 기간에는 시험 공부만 했었기에, 두 개를 동시에 하는 색다른 경험을 할 수 있음에도 좋은 기회였던 것 같습니다.😀
이번 기회에 회고 작성을 진행하려고 합니다! 회고 방식은 KPT 방식을 적용해 보았습니다.
프리코스 1주차에 들어가기 앞서 매우 간단한 저만의 MVC 클린코드 기준을 세워봤습니다.
그간 해보고 주워듣고.. 해서 얻은 지식을 토대로 말이죠.
매주 프리코스를 진행하면서, 여러사람과 코드 리뷰도 주고 받으면서 점차 고도화시킬 예정입니다.
메서드 이름에 최대한 많은 정보가 담기도록 한다.
하나의 메서드는 하나의 기능만 가지도록 구현한다.
매개변수의 이름에도 의미를 잘 전달할 수 있게 구현한다.
모든 클래스가 단일 책임 원칙을 지키도록 설계한다.
메서드에서 서로 결이 다른 기능이 나열되면, 한 칸 띄고 작성한다. ex) return이 올 때 한 칸 띄기.
📍 문제 요구 사항
문제를 처음 보고 굉장히 쉽게 느껴졌습니다. 그런데..
"애매한 건 스스로 판단하여 구현" <- 이 문장이 제 발목을 잡을 줄은 몰랐습니다.
구분자는 특수문자만 되는건가?
구분자는 여러번 선언 가능할까?
-부호는 어떻게 처리되는 걸까?
구분자로 등록할 수 있는 크기에 제한이 있을까? ex) 구분자로 !@#$%^도 가능할까?
문제만으로는 알 수 없는 다양한 고민을 상당히 오래했던 것 같습니다.
그러다 예시로 나온 테스트코드를 보며, 그 기준으로 애매한 건 다 배제하고 진행하기로 결정하고 개발 시작!
틈틈히 개발해서 약 3일만에 구현을 완료했습니다.
📍 Keep
저의 클린코드 기준 5개는 기본적으로 지키면서 코딩하면 좋은 것들이기에 그대로 유지하면 좋을 것 같습니다.
클래스와 메서드를 무겁지 않게 설정하고 강연결 구조를 막도록 설계하는 건 어느정도 해낼 수 있었습니다.
이번에 처음으로 commit 컨벤션에 집중해서 commit 작성을 진행했습니다. 전에는 항상 -m 으로 메세지를 작성했는데, 더 길고 자세하게 작성하는 게 얼마나 좋은지 깨달았고, 그대로 적용하면 될 것 같습니다.
마지막으로 코드리뷰를 주고 받는 것도 참 좋았고, 계속하고 싶다는 생각이 들었습니다.
내 코드가 항상 정답일 수는 없기에 여러사람의 의견을 듣고, 내 기준을 더 명확히 세워야겠다고 다짐했습니다.🤩
📍 Problem
MVC 모델을 너무 유연하게 생각했습니다.
하면 할수록 미궁에 빠지는 부분이 많았습니다. 특히 기준을 세우더라도 새로운 상황이 놓아지면 똑같이 처음으로 돌아오는 느낌이었습니다. 이번에 가장 많이 고민했던 내용입니다.
- 부호 검증 로직을 어떻게 구현할까?
1. - 검증 로직을 위한 클래스를 만들고 역할을 부여한다.
2. - 검증 로직을 util로 빼서 정적 메서드 처리를 진행한다.
3. controller에서 접근한다.
원래 기존의 저였다면 1,2 번 중에서 고민했을 터인데, 이번엔 좀 다르게 접근하고 싶었습니다.
뭔가 유연하게 controller에서 처리해보면 어떨까? 라는 생각과함께..
3번으로 결정하고 설계해 보았는데, controller의 설계 방향과는 결이 좀 다른 느낌이 들면서 후회했습니다. ㅎㅎ!
controller에는 view와 model을 이어주는 내용만 들어가면 더 완벽하겠다는 생각이 들었습니다.
docs 파일 관리를 잘 못했습니다.
사실 개발하면서 기획이 바뀌는 건 당연한 거라고 생각합니다. 다만 그 기획의 변경이 너무 잦았습니다.
특히 처음에 \n을 문자열 그대로만 해석해서 구현했다가 \\n으로 처리해야한다는 사실을 깨달은 순간, 줄바꿈 문자라고 생각하지 않았던 내가 어이없었고 얼마나 생각없이 docs를 설계했는지 알게 되었습니다.
그 외에도 클래스 책임이 많아서 새로운 클래스를 만든다던지, enum으로 뺀다던지 다양하게 docs를 수정했던 것 같습니다.
테스트 코드를 꼭 짜야겠다는 생각이 들었습니다.
테스트 코드 없이 하나하나 실행시켜보는 모습을 보니까 지치더라구요..
테스트 코드를 짜는 데 드는 시간이 모든 경우의 수를 고려해 입력하는 시간보다 효율적이라는 생각이 들었습니다.🥲
📍 Try
프리코스 2주차에서는
1. MVC 모델에 더 맞는 코드 짜도록 노력하기.
2. docs 파일 최대한 완벽하게 짜고 넘어가기.
3. 테스트코드 짜기.
전부 당장 실행 가능한 내용들이기에 바로 적용할 예정입니다.
📍 배운점
1. 후에 추가될 로직도 생각해서 설계를 해야한다.
저는 항상 지금 보이는 로직만 생각해서 설계를 진행했던 것 같습니다. 그치만 서비스란 게 계속해서 기능이 추가된다고 생각이 들면서 미래를 위해 코드를 짜야한다는 생각이 들었습니다.
또 docs 파일이 너무 자주 바뀌니까 많이 힘들더라구요.. 맨 처음에 설계가 얼마나 중요한지 다시 한번 깨닫게 되었습니다.
2. 인터페이스도 사용해보자.
제가 코드 짜면서 인터페이스 활용을 생각 안 하고 짜더라구요. 객체 지향의 장점 중 하나인데 말입니다.
다음부턴 공통으로 관리되는 부분이 있다면 과감하게 써볼 예정입니다.
3.상수화에 대해 더욱 고민해보자. 상수로 선언 안 하는게 더 직관적일 때도 있다.
이번 코드에는 하드코딩을 하지 않기 위해서 전부 상수로 빼보았는데요.
사실 자바에서 제공하는 라이브러리에 들어가봐도 전부 상수처리한 로직은 거의 없다구요??
그래서 지금 내가 너무 상수에 얽매여 있지 않나는 생각이 들었습니다.
매직넘버가 항상 나쁜 건 아니다! 라는 것도 이번에 배울 수 있었습니다.
📍 마무리
2주차 시작하고 벌써 3일이 지났습니다. 슬슬 개발 들어가야겠어요..!
모두 많이 배우고 행복한 프리코스 보내길 응원하겠습니다.👀
'우테코 7기 프리코스' 카테고리의 다른 글
| 우아한 테크코스 7기 프리코스 4주차 회고 (0) | 2024.11.23 |
|---|---|
| 우아한 테크코스 7기 프리코스 3주차 회고 (0) | 2024.11.04 |
| 우아한 테크코스 7기 프리코스 2주차 회고 (0) | 2024.10.28 |