회고

https://github.com/woowacourse-precourse/java-onboarding 

우아한테크코스 5기 백엔드에 지원하여 프리코스에 참가하였다. 1주차는 git과 JAVA, 그리고 미션 사이클에 익숙해지는 시간이었다.

IDEA는 IntelliJ, Java version은 Java 11로 진행하였다. 이클립스만 사용해봤기 때문에 생소한 IDEA라 사용법을 익히는 과정이 길었다.

또한 다른 동료들의 클린 코드를 위해 고민한 흔적을 보며 한층 성장할 수 있었던 기회였다. 차주부터는 본인도 클린 코드 작성을 위해 노력해야겠다고 다짐했다.

1. 기능 목록

1. 문제 1

   1번 문제에서 특히, 문제를 잘못 이해했었다. 처음에 문제를 더하거나 곱해서 나올 수 있는 최대값을 구하는 문제인 줄 알았으나 테스트 케이스를 통해 모순을 찾아냈고 제대로 해결할 수 있었다.

   • 각 자리수를 모두 더하거나 모두 곱해 가장 큰수 구하는 기능
   • 예외처리
     1. 왼쪽은 홀수, 오른쪽은 짝수가 아닐 경우
     2. 첫페이지와 끝페이지 제외
     3. 책이기 때문에 연속된 페이지가 아닐 경우
     4. list의 길이가 2가 아닐 경우

2. 문제 2

   • 재귀 사용해서 끝까지 중복 제거
   • 중복 삭제 기능
   • List를 String으로 바꾸는 기능
   • 원래 값과 비교해서 재귀 끝내는 조건 확인하는 기능

3. 문제 3

   • 재귀로 풀이한다. 숫자를 1씩 증가하며 clap 함수로 박수 횟수를 계산한다.
   • 특정 숫자를 10으로 나눠 자리수별로 확인한다. 3,6,9에 해당하면 cnt +1.
   • 만약 해당 숫자가 0이 될 경우(자리수를 다 확인함) 재귀에서 빠져나오면서 횟수를 return한다.

4. 문제 4

   • 아스키코드 사용
   • String to Char
   • 예외처리 isAlphabetic

5. 문제 5

   • 오만원, 만원, 오천원, 천원, 오백원, 백원, 오십원, 십원, 일원 (8개) 순서
   • 화폐 위주로
   • 예외 : 제한 사항 외 문제가 될만한 것 없어보인다.

6. 문제 6

   • 닉네임이 두글자 이상이 연속적으로 중복인지 체크
   • 이메일 문자열 오름차순 정렬
   • 예외 처리
     • 이메일은 이메일 형식, 전체 길이 11이상 20 미만
     • 닉네임이 한글인지
     • 같은 이메일이 없는지

7. 문제 7

   • friends별 친구 저장
   • score 계산
     • 함께 아는 친구 score 계산
     • 방문자 score 계산
     • user의 친구 제외해야함
   • 추천 친구 정렬

2. 배운 점 정리

배운점과 개선할 점을 정리했다.

0. 테스트케이스에 대한 고민

Slack의 테스트케이스 방에서 많은 사람들이 테스트케이스를 공유하고 있는 것을 뒤늦게 알았다. 다음 미션부터는 적극적으로 활용하여 제가 생각한 테스트케이스도 공유하고 싶다는 생각을 하였으나..

차주 미션부터는 테스트케이스 공유를 지양한다. 다소 아쉽지만 이번 주차에 배운 감각을 활용해 혼자서 테스트 케이스를 생각해보는 힘을 기루는 기회가 되었으면 좋겠다.

1. git commit message 컨벤션을 지킬 것

“기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.”

이 문장의 뜻을 기능 요구사항 7가지 문제의 1문제를 기능으로 여겨 문제당 1번씩 커밋하라는 뜻으로 이해하여 진행하였으나.. 그것이 아님을 5일차에 깨달았다.. 기능 목록은 작성하였는데, 그 단계를 커밋으로 기록하지 못해 많은 아쉬움이 남는다.

그러나 커밋 컨벤션을 지키고, 가독성이 높은 커밋 메시지를 작성하기 위해 많은 시간을 투자했다.

# 커밋 컨벤션
# Angular JS Git Commit Message Conventions Document.

  + feat : 새로운 기능
  + fix : 버그 수정
  + build : 빌드 관련 파일 수정
  + chore : 그 외 자잘한 수정
  + ci : CI 관련 설정 수정
  + docs : 문서 수정
  + style : 코드 스타일 혹은 포맷 등
  + refactor : 코드 리팩토링
  + test : 테스트 코드 수정

다른 문제에 대한 커밋인데 커밋메시지가 같아지는 현상이 발생해 해당 커밋이 어떤 문제에 관련된 것인지 파악이 되지 않는다고 판단하여 (ex. docs : add checkliks) head에 정보를 적듯 괄호로 표시해주었다.

특히, 이 과정에서 이미 push한 커밋 메시지를 변경하는 법을 익힐 수 있었다.
GIT - Commit한 메세지 문구 수정하기 (Commit 메세지 오타 수정)

1. 마지막 Commit 메시지 수정
   git commit --amend

2. 이전에 Commit 메세지 수정
   git rebase -i HEAD~3 # 마지막에서 3번째 커밋까지 불러오기

3. pick 커밋번호 커밋메시지 가 뜨면 pick을 reword로 바꾼 후 저장, 터미널 종료
   → Commit 메시지에 대한 화면이 호출됨
   

4. 커밋 메시지 변경하기

5. remote에 이미 push했을 경우
   git push --force 브랜치이름 : force하게 덮어쓰기 (위험하다)

+ IntelliJ에서 한글이 정상적으로 나오지 않는 현상..?

터미널에서 commit 메시지를 한글로 작성할 때 지속해서 이상하게 작성된다.. 해결 방법을 찾는 중이다. 우선은 메모장에 작성한 후 Ctrl+C, V 하는 방법을 선택..^^

• 유니코드로 적용되는 것인지..? 블로그를 참고해 변경했지만 여전히 안되는 것 같다.
  IntelliJ에서 .properties의 한글이 유니코드로 나오는 경우
  

• +) 커밋과 관련해 프리코스 커뮤니티에 올라온 좋은 글을 발견했다.
  Git commit message convention

2. 불필요한 주석을 달지 않을 것.

코드의 가독성을 위해 주석을 작성했는데, 변수 이름, 함수(메서드)이름을 통해 어떤 의도인지가 드러난다면 굳이 주석을 달지 않는 것이 좋다는 피드백을 받았다. 따라서 가능한 이름을 통해 의도를 드러내기 위한 이름 명명법을 찾아보았다.(하단에 있음)

3. IDE의 코드 자동 정렬 기능을 활용할 것.

Ctrl+Alt+L

IDE의 코드 자동 정렬 기능을 사용하면 더 깔끔한 코드를 볼 수 있다.

4. 자바 코드 컨벤션을 지킬 것

프리코스 2주차에선 요구되는 사항이다. 하지만 다른 분들의 1주차 회고를 보니, 자바 코드 컨벤션을 신경 쓴 흔적이 보였다. 코드 컨벤션이라.. commit 컨벤션은 들어봤어도 코드 컨벤션은 생소해 열심히 찾아보았고 본인의 코드가 흔히 말하는 ‘악취나는 코드’임을 깨달았다.. 그러나 자바 지식이 없어 신경쓰지 못한 새로운 분야를 알게되어 기쁘다.

• IDE에 코드 컨벤션을 적용하는 것이 가능하다고 한다. 차주부터는 적용할 것.
  IntelliJ에 Google Java Style Guide 적용하기 (feat. Naver)

• 우테코 클린코드 원칙
  woowacourse-docs/styleguide/java at main · woowacourse/woowacourse-docs

  1. 한 메서드에 오직 한 단계의 들여쓰기(indent)만 허용했는가?
     • 반복문과 조건문을 사용할 때 마다 늘어나는 들여쓰기를, 메소드를 사용해서 줄여야한다.
  2. else 예약어를 쓰지 않았는가?
  3. 모든 원시값과 문자열을 포장했는가?
  4. 콜렉션에 대해 일급 콜렉션을 적용했는가?
  5. 3개 이상의 인스턴스 변수를 가진 클래스를 구현하지 않았는가?
     • 쉽지 않은 연습일 수 있다. 가능하면 인스턴스 변수의 수를 줄이기 위해 노력한다.
  6. getter/setter 없이 구현했는가?
     • 핵심 로직을 구현하는 도메인 객체에 getter/setter를 쓰지 않고 구현했는가?
     • 단, DTO는 허용한다.
  7. 메소드의 인자 수를 제한했는가?
     • 4개 이상의 인자는 허용하지 않는다.
     • 3개도 가능하면 줄이기 위해 노력해 본다.
  8. 코드 한 줄에 점(.)을 하나만 허용했는가?
     • 디미터(Demeter)의 법칙(“친구하고만 대화하라”)을 지켰는가?
     • 예를 들어 location.current.representation.substring(0, 1)와 같이 여러 개의 점(.)이 등장하면 리팩토링할 부분을 찾아본다.
  9. 메소드가 한가지 일만 담당하도록 구현했는가?
  10. 클래스를 작게 유지하기 위해 노력했는가?

5. 변수와 함수명을 잘 짓기 : 클린 코드의 첫걸음

개발자 영어
개발자가 가장 잘할 줄 알아야 하는 언어가 영어라고 하셨던 동아리 선배의 말씀이 생각난다. 본인은 여러 변수를 사용하기 위해 선언할 때, 리팩토링 과정에서 함수명을 고민할 때 ‘이 단어가 영어로 뭐더라?’ 생각하며 파파고에 찾아보면서 진행하였다. 변수명을 잘 짓는 것은 개인의 센스라 생각해 마음대로 작성하였지만, 1주차가 끝나고 여러 다른 분들의 회고를 보며 ‘틀리게 이름을 정했구나’ 깨달을 수 있었다. 관련 레퍼런스를 찾으며 다음과 같은 좋은 글을 발견할 수 있었다.

• 함수는 동작을 나타내므로 현재형 동사로 시작해야한다. ex) startGame()
  • 현재형 동사로 시작하는 문장은 명령형을 나타낸다.
• 변수는 값을 나타내므로 동사 원형으로 시작하면 안된다.
  • playVideo는 오답. isPlaying으로 지어야한다.
• 축약어 사용하지 않는다.
  • 많은 축약어를 사용하였는데, 이점을 유의해야겠다고 생각했다.
• 동사는 두개 이상 못쓴다.
• 3인칭 단수를 사용한다.

3. 추가 reference

• [우테코] [프리코스] 클린 코드 체크 리스트 읽기