TIL 230602 : 튜터님의 코드와 비교해보는 코드리뷰 (키오스크 주문 프로그램)

금요일 리뷰마치고 튜터님 코드와 내 코드랑 비교하고 TIL정리를 깜빡해서 이제야 올린다.

---

튜터님의 코드리뷰 시간

키오스크 프로그램 과제를 마무리하고 튜터님의 코드를 통해 리뷰해보는 시간이 있었다.

내가 짠 코드와 비교할 수 있는 시간이라 굉장히 보고 와닿은 것들이 많았는데 아래에 정리해보려 한다.

 

1. 한 메소드당 10줄 이상 넘지 않는 것이 좋다.

(왼쪽) 작은 기능별로 나누고 기능을 다른 메소드에 추가하며 길이를 줄였다. (오른쪽) 냅다 코드 박아넣어버렸다.

튜터님의 코드를 처음 봤을 때 든 느낌은 '깔끔하다.'였다.

한 메소드당 10줄이상 넘어가지 않게 짜는게 좋다고 말씀하셨는데, 그 말을 듣고 다시 코드를 보니 그래서 별다른 주석 없이도 이해가 잘 됐던 것 같다.

 

2. 프린트 기능들을 메소드로 정리해두면 깔끔하다.

반복되는 'System.out.println' 명령어들은 메소드로 정리해서 해당 매개변수를 받아 자동으로 출력해두는 메소드를 만들어 두셨다.

그리고 입력을 받는 메소드도 아예 따로 빼서 handleConfirmationInput()으로 실행하는 모습이다.

그렇다보니 코드를 처음보는 나도 '아 확인을 묻는 프린트 메소드구나. 그리고 밑에 입력값을 받는 메소드를 따로 정리해두고 호출했구나.'라는 이해가 바로 됐다.

 

3. 접근제어자는 명시해두자. Public일지라도.

나름 용기낸 질문..

튜터님의 코드에서는 public접근제어자를 포함해 private등 접근제어자들이 굉장히 꼼꼼히 달아준 것을 느꼈다.

private야 외부접근을 차단해 의도치 않은 접근을 차단하므로 어느정도 납득이 됐는데, public은 굳이 안써줘도 같은 패키지안이니까 괜찮지않나? 혹시 패키지가 더 생겼을 때를 대비해서 미리미리 명시하는 게 좋은것인가? 라는 생각에 질문을 드렸다.

(왼쪽) 튜터님 코드. (오른쪽) 나의 코드. / 나는 public은 굳이 안써도 작동이 잘 되니까 넣어주지 않았었다.

 

접근제어자를 명시해주는 것은 기능적인 측면에서라도 꼭 넣어줘야하지만, 개발자가 본인의 의도를 분명히 하는 면에서도 의미가 있어요. '이 변수는 public하게 활용할 것이다. 이 메소드는 private하게만 쓰일것이다.' 라는 의도를 분명히 전해주기도 하거든요. 결론적으로 접근제어자는 다 챙겨서 달아주는 것을 권장합니다.

---

어떻게 static메모리를 관리하거나, 다른 기술적 측면들보다도 코드의 가독성이 무엇인지 몸으로 체득한 경험이었다. 다시한번 '구현은 끝이 아닌 시작.'이라는 사실을 느꼈다. 바로 다음주에 시작될 팀과제에서 적용시켜볼 내용들이다.

그리고 예전에 얼핏 들었던 클린코드라는게 이런건가..?? 싶었다. 이것도 알아봐야겠다.

 

다음부터 적용해볼 사항
 - 한 메소드 길게 안 쓰기.
 - 반복적 프린트기능은 메소드로 따로 구성해보기.
 - 접근제어자 꼼꼼히 달아두기.