우아한 프리코스 2주차
우아한 프리코스 2주차
1주차 과제를 완료하고…
우아한 프리코스 1주차 과제를 완료하고 참가자들에게 공통 피드백이 주어졌다. 내가 생각하기에 유의미한 정보라고 판단되는 몇가지를 가져왔으니 같이 보자
1. 축약하지 않는다
의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.
누구나 실은 클래스, 메서드, 또는 변수의 이름을 줄이려는 유혹에 곧잘 빠지곤 한다. 그런 유혹을 뿌리쳐라. 축약은 혼란을 야기하며, 더 큰 문제를 숨기는 경향이 있다. 클래스와 메서드 이름을 한 두 단어로 유지하려고 노력하고 문맥을 중복하는 이름을 자제하자. 클래스 이름이 Order라면 shipOrder라고 메서드 이름을 지을 필요가 없다. 짧게 ship이라고 하면 클라이언트에서는 order.ship()라고 호출하며, 간결한 호출의 표현이 된다.
객체 지향 생활 체조 원칙 5: 줄여쓰지 않는다(축약 금지)
공백도 코딩 컨벤션이다
if, for, while문 사이의 공백도 코딩 컨벤션이다.
공백 라인을 의미 있게 사용한다
공백 라인을 의미 있게 사용하는 것이 좋아 보이며, 문맥을 분리하는 부분에 사용하는 것이 좋다. 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.
Java에서 제공하는 API를 적극 활용한다
함수(메서드)를 직접 구현하기 전에 API에서 해당 함수를 제공하는지 확인한다. 예를 들어 사용자를 출력할 때 사용자가 둘 이상인 경우 쉼표(,) 기반 문자열을 출력하도록 다음과 같이 구현할 수 있다.
1
2
var members = List.of("pobi", "jason");
var result = String.join(",", members); // pobi,jason
배열 대신 컬렉션을 사용한다
컬렉션(List, Set, Map 등)을 사용하면 다양한 API를 사용하여 데이터를 조작할 수 있다. 예를 들어 List에 “pobi” 값이 있는지 다음과 같이 확인할 수 있다.
1
2
var members = List.of("pobi", "jason");
var result = members.contains("pobi"); // true
다음과 같은 피드백 내용이 내가 생각하기에 주요한 피드백 내용이였다고 생각하고 이 중에서도 몇가지를 내 경험을 추가해 공유하고자 한다.
공백도 컨벤션이고 공백을 활용하라
나는 공백도 컨벤션이라는 말과 공백을 의미있게 활용하라는 점이 가장 참신했다. 내가 코드를 짤 때는 자동으로 enter를 치면 indent blank size가 결정되어 있었기 때문에 공백도 컨벤션이라는 생각을 해보지 못했다. 하지만 이 글을 보고 내가 진행하고 있는 프로젝트에서 팀원으로부터 다음과 같은 pr을 받게 되었는데, 공백이 컨벤션이고 공백라인을 의미있기 활용하라는 것이 왜 필요한 지 이해할 수 있었다
이미지를 보면 다음과 같이 indent blank size가 1로 되어있는데, 이 친구가 IDE 설정을 건드렸거나, 다른 곳에 코드를 복사해놨다가 붙여넣으면서 다음과 같이 blank size가 이상하게 지정된 것 같다. 이것 때문에 코드를 알아보기 힘들었고, 나는 이 내용을 공유하면 좋겠다고 생각해서 다음과 같은 review를 남겼다.
배열 대신 Collection을 활용하라
다음으론, 배열 대신 컬렉션을 사용하라는 피드백 내용이 좋았다. 나는 Java에 대해서 깊게 공부해본 적이 없었기 때문에 컬렉션과 배열의 차이에 대해 고민해본 적이 없었다. 그런데, 이번 피드백을 통해 둘의 차이에 대해 찾아보고 공부하게 되었다.
Collection을 사용하면 데이터 조작의 이점이 있고, 기존 Array를 보완하기 위해 만들어진 것이기 때문에 사용하면 좋다는게 글의 내용이다. 그래서 앞으로는 Collection을 적극적으로 활용해야겠다고 생각하게 되었다.
2주차 과제 구현과 코드리뷰
디렉토리 구조
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
📦racingcar
┃
┣-📂controller
┃ ┃
┃ ┣-📜GameController.java
┃ ┃
┃ ┗-📂util
┃ ┃
┃ ┗-📜Parser.java
┃
┣-📂model
┃ ┃
┃ ┣-📜Car.java
┃ ┃
┃ ┗-📜RacingGame.java
┃
┣-📂validator
┃ ┃
┃ ┗-📜Validator.java
┃
┣-📂execption
┃ ┃
┃ ┣ ErrorCode.java
┃ ┃
┃ ┗ ExceptionHandler.java
┃
┣-📂view
┃ ┃
┃ ┣-📜InputView.java
┃ ┃
┃ ┗-📜OutputView.java
┃
┗-📜Application.java
피드백 내용 + α
내 코드에 대한 코드 리뷰에서 다음과 같은 리뷰를 받았다
Validator에 정의된 시도 횟수에 대한 유효성 검증을 하는 함수에서 값을 검증하는 것만이 아니라 반환도 하다보니 책임이 명확히 분리되지 않고 책임이 다소 섞인 느낌이 들었다는 것이다. 나도 내가 책임을 명확히 분리하지 못한 코드를 적었다고 생각하고 다음 과제에서는 책임이 명확히 분리된 코드를 작성해야겠다고 생각하게 되었다.
한편, “Validation 처리에 대한 전용 클래스를 따로 만들어야 하는가?”에 대한 토론이 우테코 디스코드에서 이뤄졌다. 나도 그랬지만, 다들 Validation 처리에 대한 고민이 있었던 것 같다.
이 토론 내용 중 몇가지 좋은 내용이 있었는데, 아래가 그 내용이다.
분리 시점을 테스트로 판단한다.
도메인 로직에 대한 검증을 따로 나눌 필요가 없다.
결론적으로, 내가 판단하기에는 도메인의 사이즈와 테스트 코드의 작성 시점으로 판단하는 게 꽤 괜찮은 생각인 것 같다. 또, 도메인 로직과 유효성 검증에 대한 class 책임을 굳이 분류할 필요는 없을 것 같다. 앞으로 더 코드를 작성해보면서 나에게 맞는 방법 혹은 내가 옳다고 생각하는 방법을 확립하는게 중요할 것 같다. 또 fail fast에 대한 내용을 참고해도 좋을 것 같다.
다른 사람의 코드 중 좋았던 부분
다른 사람의 코드 중 좋았던 부분이 몇가지 있었는데, 그 중 특히 인상적인 부분이 있었다.
바로, Facade 패턴이다. Facade 패턴이라는게 세상에 존재하는 지도 몰랐던 나로써는 꽤 충격이였다. 아마 비즈니스 로직 상 의존성 주입 시 너무 많은 Controller나 Service에 너무 많은 인자가 들어가다 보니(의존성 주입이 과도해짐) Facade 패턴을 이용한 것 같다. 의존성 주입을 받을 수 있는 Facade class를 만들고 작은 규모(?)의 코드들을 의존성 주입을 이 class로 받아 나중에 Controller나 Service에서 Facade class만 의존성 주입을 받으면 되니 굉장한 장점이 있다고 생각된다.
느낀 점
생각보다 내가 java에 대한 기초지식이 부족하고, 좋은 객체 지향 설계에 대한 고민을 많이 해보지 않았다는게 확 느껴졌다. 다른 사람의 코드를 보고 내 코드와 비교해봤을 때, 의존성이나 책임에 대한 명확한 분리에 대한 이해가 부족해보였다. 앞으로 프리코스를 진행하면서 더 고민해보고 실력을 늘려야겠다.