[우테코 7기] 백엔드 프리코스 1주차 회고🌒

📍내가 정한 규칙
1 매일 적어도 2-3시간 투자
2 피어 리뷰 최소 2개 이상

 

 

지원 완료!
진짜 너무 너무 잘 하고 싶다. 파이팅.

나에게 회고의 목적은 과거를 돌아보고 스스로를 점검하는 데 있다. 정신없이 앞으로 나아가다가 잠시 브레이크를 걸어주는 역할..이라고 생각한다. 1주차의 회고와 4주차의 회고가 어떻게 달라질지 너무 궁금하다! 회고도 쌓여가는 경험을 되돌아보고 기록하는 용도로 작성하는 것이다.

시간이 지나면 처음 구현을 시작할 때 세운 계획의 의도가 기억나지 않을 때도 있는데... 이럴 때 회고는 중요한 참고 자료가 되기에... 처음 세웠던 규칙을 까먹지 말고 4주차까지 달려보자!!! 회고 작성은 주 단위로 하고, 일일목표, 공부한 것, 진행상황 등을 작성하려고 한다!😁 자자 파이팅.

0. 관련 링크들

---

https://github.com/woowacourse-precourse/java-calculator-7/pull/471

[문자열 덧셈 계산기] 이승연 미션 제출합니다. by dltmddus02 · Pull Request #471 · woowacourse-precourse/java-

https://nourzoo.notion.site/1210e7436b2d80909c0cd4d4f70bfaa9?pvs=4

우테코 일일목표 | Notion

 

1. 요구사항

---

 

 

)

2. 고민한 것들

---

md 파일은 왜 있을까?

우테코에서
기능을 구현하기 전 README.md에 구현할 기능 목록을 정리해 추가한다
이렇게 기능명세서의 중요성을 굵은 표시가 되어 있을 정도로 강조했다. 강조하는 이유를 생각해보았다.

나도 학부생으로서 여러 플젝을 해보며 선배들 깃헙을

굉장히

참고했지만 내가 깃헙을 볼 때 가장 먼저 보는 것은 리드미 파일이었다. 리드미 파일이 없으면 일단 건너뛰기... 코드를 이해하기 위해 리드미 파일이 큰 역할을 한다. 또한 프로젝트를 시작하기 전, 프로젝트에 대해 다시 생각해보고 정리하라는 뜻으로도 받아들였다.

내가 정의한 "잘 쓰여진 md파일"

- 가독성이 좋고 깔끔하게 잘 분류한 파일
- 기능별로 구분이 잘 되어 있는 파일
- 결과물을 한 눈에 알 수 있는 파일

 

 

이렇게 README.md 파일을 작성해보았다.
동작에 따른 실행과 에러를 구분하고, 할일목록으로 체크해가며 할 수 있게 정리했다.
+프로젝트 설명, 목차, 프로젝트 설치 및 실행 방법, 테스트를 더 추가해서 한 눈에 보기 쉽게 정리해야겠다.

패키지 나누는 기준

10/18
현재 Application.java 파일만 있지만, 앞으로 작성할 코드를 어느 패키지와 클래스에 배치할지 고민해보았다. 서치해본 결과, 자바에는 도메인형과 계층형이 있다는 것을 알게되었다.
1주차에는 기능에 따라 패키지를 구분하는 도메인형으로 구현해보려고 한다. 후에 피드백을 받게 되면 그 피드백에 맞게 또 공부하면 되니까!

• input: 사용자로부터 입력을 처리하는 클래스들
• output: 계산 결과를 출력하는 클래스들
• constant : 입력과 출력 메시지 상수를 관리하는 클래스들
• util: 반복적으로 사용되거나 필요에 따라 사용하는 유틸리티 함수들
• calculator: 주요기능과 관련된 비즈니스 로직을 구현하는 패키지

이렇게 구현해보려고 한다!

환경 설정

10/15
먼저 깃헙에 있는 저장소를 fork&clone 해왔다.

(벌써 700명이 넘게 fork를... 우테코 화력 미쳤당...)

위의 요구사항에서 "자바 버전 21인지 확인" 때문에 터미널에 검색해 본 결과... 안타깝게도 작년에 설치했던 17버전이었다.

  ->업데이트 먼저 하자.

jdk 21 다운받고, 인텔리제이 JDK 버전까지 업그레이드 완료했다.

10/16
어제 업그레이드를 제대로 한 것이 아니었다.
JDK 21 설치한 후 인텔리제이에서 설정한 줄 알았는데 gradle 버전과 맞지 않아서 빌드 자체가 안 되는 문제가 생겼다.
무수한 구글링을 해봤지만 해결되지 않았고, 약 3시간동안 삽질하다가 터미널에서 gradle 버전 8.8로 업데이트를 한 후 다시 프로젝트 생성하여 인텔리제이 open했더니 겨우 해결되었다.

브랜치 생성

오늘 프리코스 과제 제출 페이지를 다시 보니 '기능 구현을 위한 브랜치 생성' 단계를 빠뜨린 것을 알아챘다.
처음에 branck를 안 파고 main 함수에 커밋을 하나 올려놓았는데 이걸 취소하는데 너무 시간을 많이 쏟아버렸다.
처음 만들었던 저장소 삭제하고 다시 fork 받아와서 문제 해결했다...
깃허브는 왜 항상 새롭게 어려운지...

3. 구현 코드

---

파일 구조

• constant : 프로그램 내에서 출력되는 모든 문자열 상수들을 저장한 폴더
• controller : 사용자에게 입력을 받고 그 입력을 처리하고 결과를 반환하는 컨트롤러를 저장한 폴더
• logic : 핵심 로직을 구현한 폴더
• util : 여러 클래스에서 공통적으로 사용되는 유틸리티 클래스들을 저장한 폴더

4. 배운 것들

---

폴더 구조

처음에는 폴더를 어떻게 효과적으로 분리해야 할지 고민이 너무 많아서 쉽사리 코드가 작성되지 않았다. 완벽하게 기획하고 코드를 작성하고 싶었는데, 우테코를 같이 준비하는 다른 동기분들이 올리신 어떠한 글을 보았다.

뭔가 정신이 차려지는 글이었다... 나도 이 분이랑 똑같이 고민 중인 상황이었기 때문이다. 이 글을 보고 그냥 냅다 코드를 작성하기 시작했다. 우테코의 '돌아가는 쓰레기를 만들어라'하는 말이 그런 말인가 싶기도 했다. 일단 작성하고 리펙토링 하면 되니까.
처음에는 Application.java에서 코드를 작성하기 시작했다. 작업을 진행하다 보니 반복적으로 사용되는 기능들이 많아져, 효율적으로 관리하기 위해 util 폴더가 필요했다. 그리고 입력 처리를 담당할 유틸리티 클래스가 필요했고, 핵심 로직을 구현할 클래스도 필요했다. 이렇게 나에게 폴더를 나누는 기준이 생겼고 계속해서 리펙토링 할 부분이 생기게 되었다!

깃 컨벤션

깃허브에서는 커밋 컨벤션을 찾아서 어떻게 하면 깔끔한 커밋메세지를 작성할 수 있을지 서치했다.

 

README 작성

혼자서 프로젝트를 구현할 때는 명세서는 만들지 않고 무작정 코드 작성부터 시작했었다. 이번에 프리코스에서 기능 명세를 작성해봄으로써 더 깔끔한 설계를 할 수 있었다. 처음에는 구현을 먼저 시작할지, 기능 명세를 자세하게 작성할지 고민이 되었다. 과제에서 기능 명세서를 꼭 작성하라고 강조되어 있었기 때문에 README 파일을 작성하는 데 신경을 많이 썼다.
그러나 README 파일을 너무 자세하게 작성하다 보니 구현 도중 수정해야 할 부분이 너무 많았다. 기능 구현 전에 너무 자세히 작성하는 것도 효율적이지 않다고 느꼈다. 아직은 뭐가 맞는 방법인지 모르겠다. 동기들과 의견을 나누고 적절한 비율을 맞추어 2주차부터 작성할 계획이다.

함수의 기능

하나의 함수는 하나의 기능만 수행하도록 코드를 작성해야 한다는 사실은 이미 알고 있었지만, 실제로 실천하지는 못했다. 예전에는 '일단 코드를 작성하고 나중에 분리하면 되지!'라는 생각을 갖고 있기도 했다. 하지만 이번 프리코스에서 함수의 기능 별로 분리하는 이유에 대해 생각해보았다. 가장 중요한 이유는 '재사용성'이다. 클린 코드는 다른 사람이 보기에 이해하기 쉬운 코드라고 생각한다. 함수 이름만 봐도 기능을 예측할 수 있도록 해야하고 이를 위해 함수가 하나의 기능을 하도록 나누고 적절한 네이밍을 해야 한다.
따라서 이번 프리코스에서는 실제로 함수가 길어지거나 함수의 주제에서 조금 벗어나는 부분이 생기면 과감하게 함수를 분리했다. 결과적으로 코드의 길이는 길어지고 구조가 복잡해졌지만 가독성이 좋아졌다. 클린 코드란 단순히 코드가 짧은 것이 아니라는 점을 깨달았다.

상수의 변수화

예시로 '덧셈할 문자열을 입력해 주세요.'같은 문자열이 있다. 원래의 나였으면 함수 안에 하드코딩을 했을 것이다. 하지만 이번에 값을 하드코딩하지 않고 상수로 분리해서 의미를 드러내는 이름을 만들어보았다. 하드코딩했을 때보다 상수의 의미가 분명하게 전달되어 가독성이 좋아지고 유지보수하기도 좋아졌다.

5. 느낀 점

 

---

1주차부터 쉽지 않음을 느꼈다... 하하하

 

 

과제만 봤을 때는 기능이 별로 없다고 생각하고 금방 할 수 있을 거라고 생각했는데 처음에는 환경설정한다고, 이후에는 구현하고 예외처리한다고, 마지막에는 리펙토링을 하다보니 벌써 1주차가 끝나버렸다. 그래도 처음 계획했던 하루 2-3시간은 무조건 투자하기는 지켰다!
물론 2, 3, 4주차가 더 힘들겠지만 더더더 열심히 해야지! 너무 잘 하고 싶다... 이제 12시 지나면 피어리뷰까지 가보자구-!

6. 보완할 점들

---

깃허브

이번 과제에서는 커밋을 할 때 기능단위로 하려고 최대한 노력했는데, 결과물을 보니까 잘 된건지는 모르겠다... '기능단위'라는 말을 어떻게 해석해야 할지 잘 모르겠다. 다른 동기분들의 코드를 많이 읽어보고 배워가야겠다.

static 클래스 vs 인스턴스 클래스

이 부분에 대해 잘 몰라서 util 클래스에 객체를 매번 생성하는 실수를 범해버렸다.
그런데 어떤 분이 지나가다가 들렀다면서 미친 피드백(무지 좋은 의미)를 남기시고 가셨다...
남겨주신 모든 피드백이 내가 코드짤 때 찝찝했거나 잘 몰랐던 부분이었다.
특히 static 클래스 부분!

이외에도 남겨주신 (65개의!!)많은 피드백들!

• if문에는 긍정을 사용하는게 클린코드의 원칙 (경우에 따라 다를 수 있음!)
• 모든 문자열 상수화하기 (일관되게!)
• static 클래스 vs 인스턴스 클래스 고려하여 생성자 만들기
• 결과에 Integer 아니라 long 형태까지 고려하기
• validation에 주석으로 어떤 예외인지 달기
• 완성된 기능에 대해서 - [x] 체크하기
• 폴더이름 logic 보다는 service
• 매직넘버 사용하기
• Console.close(); 콘솔 닫기(ㅋㅋㅋ진짜 처음 알았다)
• 람다-스트림 반복문 사용
• '콜렉션에 대해 일급 콜렉션을 적용했는가?' -> 캡슐화 고려하기
• 테스트코드 에러메세지와 맞는지 검증하는법
• is~~() 함수 boolean 아닐 때는 사용 지양
  (참고) 클린코드 - 함수

와... 나는 내 코드가 이렇게 고칠 부분이 많은지 몰랐다.
역시 다른 시각이 정말 중요하구나...
정말 도움이 되었고 이제 2주차는 이 피드백들 다 신경써서 더 깔끔하고 체계적으로 작성해보려고 한다!