[우아한테크코스 5기] 프리코스 마지막 4주차 다리 건너기 후기

프리코스 4주차 미션 링크

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

 

제가 제출한 코드 링크

https://github.com/70825/java-bridge/tree/70825

 

 

 

이번 미션은 요구사항을 꼼꼼히 읽어야 했습니다.

어떤 클래스는 패키지 이동 언급이 없으니 패키지 이동이 불가능하고.. 어떤 클래스는 반환 타입 변경이 불가능하고.. 어떤 클래스는 코드 변경이 불가능하고..

특히 예외처리를 Exception으로 사용하다가 요구사항을 꼼꼼히 읽었다고 생각했는데도 어디가 틀렸는지 모르겠어서 헤맸었네요 ㅋㅋ

 

이번 미션은 3주차 미션보다는 제약 사항이 많아져서, 다리에 모래주머니를 차고 한 느낌이 들었습니다.

그리고 이번 공통 피드백은 키워드 위주가 아닌 직접 코드를 통해 알려주는 방식이라 큰 도움이 되었습니다.

 

 

아래는 중요하게 생각하거나 새로운 내용을 알게 되어 적용한 내용입니다.

 

 

 

1. stream 적용

---

indent(인덴트, 들여쓰기) depth를 2까지만 허용한다.

 

1주차 온보딩 미션을 했을 때 처음 알았던 stream입니다. 아직도 새로 배울 내용이 많네요..

 

이번엔 백준 숏코딩하는 느낌으로 stream을 최대한 사용하여 대부분 메소드의 들여쓰기 깊이를 0으로 만들었습니다.

확실히 들여쓰기 깊이가 적은 것이 가독성이 매우 좋은 것 같습니다.

 

심지어 다리를 생성하는 것도 반복문 대신 stream을 사용하여 들여쓰기 깊이를 0으로 만들었는데, stream에 있을만한건 다 있는 것 같아서 신기하네요.

public List<String> makeBridge(int size) {
    List<String> bridge = Stream.generate(bridgeNumberGenerator::generate)
        .limit(size)
        .map(this::convertDirection)
        .collect(Collectors.toList());

    return bridge;
}

convertDirection 메소드는 1과 0을 U와 D로 변환해주는 메소드입니다.

---

 

 

 

2. 클래스를 분리하는 연습 - MVC 패턴 적용

---

3주차 미션 공통 피드백으로 클래스(객체)를 분리하는 것을 추가했다고 합니다.

그래서 프로그래밍 요구사항으로 각 메소드의 길이를 10줄 이내로 제한해야 했습니다.

 

저는 MVC 패턴을 적용하여 총 22개의 클래스를 만들어서 관리했습니다. 테스트쪽도 총 10개의 클래스가 있다보니 1,000줄이 살짝 넘는 코드를 작성했네요. 

 

최대한 stream을 사용했기 때문에 가장 긴 메소드의 길이는 8이였고, 가장 깊은 들여쓰기 깊이가 1이였습니다.

 

• controller
  • BridgeGameController
• domain
  • Bridge
  • BridgePrintMaker
  • Direction
  • Move
  • Range
  • Restart
  • Result
• exception
  • InvalidDirectionFormatException
  • InvalidNumberFormatException
  • InvalidRangeNumberException
  • InvalidRestrartFormatException
  • InvalidStringFormatException
• validate
  • ValidateNumberFormat
  • ValidateStringFormat
• view
  • inputView
  • outputView
• etc
  • Application
  • BridgeGame
  • BridgeGameMaker
  • BridgeNumberGenerator
  • BridgeRandomNumberGenerator

---

 

 

 

3. StringJoiner 사용

---

파이썬의 join처럼 리스트의 요소와 요소 사이에 특정 문자를 출력할 수 있는 방법이 없을까 찾아보다가 StringJoiner라는 것을 발견했습니다.

 

처음엔 "[ "를 출력하고, 원소 사이엔 " | "를 출력하고, 끝엔 " ]"를 출력해야 하는데, StringJoiner(" | ", "[ ", " ]")를 사용하면 똑같이 적용할 수 있습니다.

 

미션에서 위쪽 방향의 다리와 아래쪽 방향의 다리로 총 2개의 다리가 존재하기 때문에 2개의 StringJoiner를 사용하여 관리했습니다.

 

여기서 upMoveResult와 downMoveResult가 `사용자가 움직이는 방향`, `실제 이동할 수 있는 방향`, `출력하는 다리의 위치` 조건에 맞게 O, X, " "를 추가하도록 만들었습니다.

---

 

 

 

4. enum 제대로 사용하기

---

지난 로또 미션에서 enum을 사용하긴 했지만 이것을 왜 사용해야 하는지 제대로 감을 못잡았기도 하고, 프리코스를 통해 처음 알았던 클래스 종류이기 때문에 적용하는 것도 애를 먹었습니다.

그래서 이번엔 손에 익히게 해보자고 비슷한 상수끼리 묶어서 모두 enum으로 관리하니까 왜 사용하는지는 알 것 같습니다.

• Direction("U", "D")
• Move("O", "X", " ")
• Range(3, 20)
• Restart("R", "Q")
• Result("성공", "계속", "실패")

 

private static final 대신 enum을 사용한 것만으로도 상태와 행위를 한 곳에서 전부 관리할 수 있어서 유지보수하기도 쉽고, 코드가 어떤 역할을 하는지 유추하기도 매우 쉬웠습니다.

만약 private static final로 관리했으면 모든 로직들이 Service에서 관리해야하니 한 파일에 너무 많은 메소드가 들어가 생산성이 떨어졌을 것 같네요.

---

 

 

 

5. 함수형 인터페이스 적용

---

로또 미션에서 BiPredicate를 사용했지만, 그때 당시엔 이게 함수형 인터페이스인지도 몰랐었습니다. 애초에 함수형 인터페이스라는 것조차도 몰랐었구요.

그러다가 이번 미션에서 BridgeNumberGenerator 클래스에 @FunctionalInterface가 붙어서 tecoble과 테코톡을 통해 람다와 함수형 인터페이스에 대해 공부하였고, BiPredicate가 함수형 인터페이스인 것을 알고 있는 상태로 코드에 적용했습니다.

 

혹시 관련 내용을 공부하고 싶은 분은 아래 순서대로 보는 것을 추천드립니다.

 

https://www.youtube.com/watch?v=sS-_Xr5Q4V4

 

https://www.youtube.com/watch?v=gWIks_tLsFI

 

 

https://tecoble.techcourse.co.kr/post/2021-11-21-functional-interface-with-lambda/

함수형 인터페이스와 람다를 이용한 코드 중복 제거

---

 

 

 

 

6. 단위 테스트

---

이번 미션에서 가장 중요하게 생각한 부분입니다.

 

저번 미션에서 많이 만들지 못한 테스트 코드가 아쉬워서 코드 커버리지를 높이고자 열심히 작성했습니다.

특히 제대로 돌아가는 코드, 에러가 나오는 코드 모두 확인하라고 해서 많은 테스트 메소드를 작성했네요.

 

몇 개가 있는지 확인해보니까 기본 제공 3개 + 새로 만든 메소드 22개로 총 25개의 테스트 메소드가 존재했습니다.

이렇게 given, when, then을 사용한 테스트 메소드도 존재하고

 

이렇게 @ValueSource, @CsvSource, @MethodSource를 사용한 테스트도 만들었습니다.

---

 

 

 

 

7. 그 외 적용한 기능

---

- 일급 컬렉션 사용

자동 생성된 다리에 Bridge 라는 일급 컬렉션을 적용했습니다.

원래 다리 출력도 Bridge에 하려고 했는데, setter가 들어가면 일급 컬렉션이 아니라고 들었기 때문에 사용하지 않게 됐습니다.

https://hello70825.tistory.com/504

여기에 간단하게 일급 컬렉션에 대해 적은 내용이 있습니다.

 

 

- 커스텀 예외처리 사용

이번 미션도 커스텀 예외처리 클래스가 몇 개되지 않아 커스텀 예외를 사용하면 코드가 깔끔했지만, 나중에 규모가 큰 프로젝트에서는 커스텀 예외처리가 좋을까하는 고민도 해야할 필요성을 느꼈습니다.

 

 

- 정규표현식 적용

validate를 작성할 때, 문자를 입력하는지 혹은 숫자를 입력하는지 확인할 수 있도록 간단하게 적용했습니다.

 

 

- 객체지향 생활 체조 원칙 최대한 지키기 (완전히 지킨 내용은 노란 배경색)

1. 한 메소드에 오직 한 단계의 들여쓰기만 한다.

2. else 예약어를 쓰지 않는다.

3. 모든 원시 값과 문자열을 포장한다.

4. 한 줄에 점을 하나만 찍는다.

5. 줄여 쓰지 않는다.

6. 모든 엔티티를 작게 유지한다. (권장: 하나의 클래스에 50줄 이내로 작성)

7. 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.

8. 일급 컬렉션을 쓴다.

9. getter / setter / 프로퍼티를 쓰지 않는다.

역시 지키기 쉽지 않네요.

 

 

- 프리코스 프로그래밍 요구사항 최대한 지키기 (완전히 지킨 내용은 노란 배경색)

1. 프로그래밍 요구사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

2. indent(인덴트, 들여쓰기) depth를 2까지만 허용한다.

3. 삼항 연산자를 쓰지 않는다.

4. 함수가 한 가지 일만 하도록 최대한 작게 만든다.

5. JUnit 5와 AssertJ를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.

6. else 예약어, switch/case는 사용하지 않는다.

7. 도메인 로직에 단위 테스트를 구현해야 한다.

8. 함수(또는 메소드)의 길이가 10라인을 넘어가지 않도록 구현한다.

9. 메소드의 파라미터 개수는 최대 3개까지만 허용한다.

---

 

 

 

 

4주라는 시간동안 많은 것을 얻어갈 수 있었습니다.객체지향 설계, 클린코드, 자바 API 사용에 대해 많이 고민해보고 배울 수 있었고, 특히 자바 기초를 알고 있냐 모르고 있냐의 차이 하나로 생산성이 확 달라지는 것을 체감할 수 있었네요.

 

프리코스를 통해 객체지향의 사실과 오해, 클린코드 책을 구매했기 때문에 차근차근 읽어볼 예정입니다.

한 달동안 많은 것을 얻어 갔는데, 정규과정으로 약 10개월을 진행하게 된다면 얼마나 더 유용하고, 좋은 내용을 배울지 궁금하네요. 합격하면 좋겠습니다 ㅎㅎ

 

 

 

 

종강까지 약 3주가 남았는데, 프리코스라는 큰 산은 넘었지만, 아직도 해야 할 일이 많네요...

그래도 이제 적어도 지하철 막차타고 집에 가는 일은 없을 것 같아 다행입니다 🤗

지금 블로그에 포스팅 할 후기 글만 최소 3개는 대기중인 상태라 미리미리 써두고 있는데, 이렇게 글을 쓰다보니까 여름방학부터 엄청 열심히 살아온 것 같아요.

 

다들 화이팅!!