[레벨1] 사다리 타기 2단계 - 사다리 게임 실행

• 저장소: https://github.com/yoondgu/java-ladder/tree/step2
• 코드리뷰 진행 PR: https://github.com/woowacourse/java-ladder/pull/217

 

기능 요구사항

• 사다리 실행 결과를 출력해야 한다.
• 개인별 이름을 입력하면 개인별 결과를 출력하고, "all"을 입력하면 전체 참여자의 실행 결과를 출력한다.

 

구현하며 고민한 내용

기존에 작성된 코드에 새로운 기능을 추가하는 일이 낯설어서 유독 쉽지 않았다.

사다리 결과를 확인하는 로직을 구현하는 데 있어, 추상적인 사고나 알고리즘 사고 능력이 부족함을 느꼈다.

그러다보니 클래스 설계가 괜찮은지 판단하기도 전보다 어려웠다.

 

그래서 리뷰 요청을 할 때, 구현에 대한 구체적인 질문 보다는

내가 구현한 방식과 어려움을 겪은 부분을 설명드리고 조언을 구했다.

 

코드리뷰에서 배운 것들

• 성장을 위한 조언
  
  • 우문현답을 해주셨다. 알고리즘이나 문제 해결력의 부재라고 생각하기보다, 답답함을 원동력으로 계속해서 노력한다면 더 성장할 수 있을 것이라는 조언을 해주셨다.
  • "조급하게 생각하기보다는, 스스로 답답함의 원인을 구체적으로 찾아보고 해소하려는 노력을 계속 해보기"로 했다!

• 원시값 포장과 복잡도
  • 모든 값들을 포장하려고 하다 보니, 2단계 미션에서는 비즈니스 로직을 위한 클래스 관계가 상당히 여러 겹의 계층으로 이루어져 너무 복잡해진 것은 아닐지? 고민이 되었다.
  • 가장 큰 원인은boolean 값을 표현하는 부분까지도 객체로 포장했기 때문이었는데, true/false 대신 도메인의 의미를 표현해주는 장점이 있어 이는 유지하고 싶었다.
  • 아래와 같은 피드백을 들으며 뭐든 극한으로 작업해보고, 중간을 찾아나가면서도 현업 관점으로 고려해보기도 잊지 말아야겠다는 새로운 배움을 얻었다.

 코드리뷰 피드백:
지금 미션에서는 내가 생각하는 방향이 적절할 수 있다.
하지만 개인 프로젝트, 팀 프로젝트를 넘어서 현업에 가게 된다면 객체 포장을 함으로써 복잡도가 올라가는 점을 인지해보기를 권장한다.
예를 들어 이번 미션의 요구 사항에서는 모든 값을 포장하라고 했지만, getter 밖에 없는 등 하는 일이 별로 없는 객체도 포장해야 하는지 생각해볼 수 있곘다.
다만 뭐든지 극한으로 작업해봐야 중간을 찾을 수 있으니 좋은 자세 같다.

• Enum 적용의 필요성
  • "Java Enum을 적용하라"는 프로그래밍 요구사항에 대해서 처음에는 당장 Enum이 꼭 필요한 부분이 없는 것 같아 사용하지 않았다.
  • 하지만 위의 "원시값 포장" 관련 피드백과 비슷한 맥락에서, 그럼에도 요구사항이 주어진 만큼 한 번 적용해보라는 조언을 들었다.
  • 그래서 1단계 리팩터링 과정과 2단계 추가 구현에서 Enum을 적용해보니 전에는 생각지 못했던 장점을 체감할 수 있었다.
  •  이를 통해 나만의 Enum 사용 기준을 정리해볼 수도 있었다.
    Java Enum은 언제 쓰면 좋을까?

• stream 잘 사용하기
  • 그동안은 stream을 다른 분들 코드에서 본 방식들만 어깨넘어 어떻게 알아가지고 겨우 써왔다. 그래서 이번에도 stream으로 원하는 종류의 map 객체(예를 들면 linkedHashMap)를 만들 줄 몰라서 stream에서 외부의 map에 put을 해주는 방식으로만 로직을 짰었다.
  • 이번 기회에 Collectors.toMap()을 사용하는 법을 직접 학습할 수 있었다.
• 전통적인 null 처리 vs Optional 타입 사용
  • Optional 타입의 존재는 알고 있었지만 이것이 널 안정성을 위함이라는 것, 전통적인 null 처리를 대신할 수 있다는 것을 알게 되었다.
  • 해당 리뷰를 받을 때에는 여전히 이에 대한 적절한 사용법을 경험적으로 체득하지는 못했다. 하지만 이를 계기로 관심이 생겼고 <좋은 코드, 나쁜 코드>에서도 해당 부분을 관심있게 읽었다. 이를 통해 이후 체스 미션에서는 적절히 사용할 수 있었다.
• 커스텀 예외
  • 이전까지는 표준 예외가 더 좋다고 생각하는 편이었는데, Index 검증이라는 공통 로직에 대해서 이를 커스텀 예외로 적용해볼 수 있었다.

 

미션 피드백 강의에서 배운 것들

가장 작은 단위에서부터 시작해보자

• 하위 개념을 구현할 때, 상위 개념에 대해 너무 생각하면 문제가 생길 수 있다는 이야기가 인상 깊었다.
• 물론 상황에 따라 in->out, out->in 방식 중 더 적합한 것이 있을 수도 있고, 이 두 방식을 핑퐁하듯이 사용할 수도 있다.

 

전체 피드백

• 이 미션에서의 코드 리뷰를 계기로 나의 기술 부채들을 목록으로 적립하기 시작했다. 그만큼 "내가 모르는 것"을 많이 알 수 있었다.
• TDD에 대해 느낀 점이 많았다. 즐겁게 코딩할 수 있었다. 이 미션을 계기로, 레벨 인터뷰에서도 TDD 관련 대답을 경험을 기반 삼아 금방 금방 말할 수 있었다.
• 요구사항과 설계에 대해 더 시간을 많이 투자해보면 좋겠다.
• 예외 사항을 더 집요하게 생각해보자.
  • 프리코스 때는 기능 목록도 최대한 원자화시켜서 오래 작성하던 버릇이 도움이 됐는데, 막상 본 과정에서는 마음이 조급한지 초심을 잃은 것 같다. 남은 미션에서는 좀 더 정확하게 파악하려고 노력하고 싶다. 고 생각했다.