onboarding 2주차

Weekly Goal

11/2~11/3

• 1주차 미션 피드백, 깃 공부, 2주차 미션 확인 후 학습, 해결 계획 세우기

11/4

• 10:30~11:30 Solid 원칙, TDD 모델, MVC 패턴, DI 구조
• 11:30~12:00 커밋 컨벤션 읽기

11/5

• camp.nextstep.edu.missionutils의 Random,Console 구조 공부하기
• JUnit 5와 AssertJ 알아보기
• 테스트 도구 사용법이 익숙하지 않다. test/java/study를 참고하여 학습
• Java Style Guide 읽기

11/6

• 미션 해결방법 도식화하기
• 도식화 바탕으로 도메인 모델링 완성하기
• 접근 제어자 연습

11/7

• 예외 처리 완료하기
• 리펙토링

Before Mission

1. 1주차 공통 피드백

1. 클래스와 메소드 이름을 한 두단어로 유지하자. 클래스에 따른 메소드의 이름이 문맥상 중복되지 않도록 하자.
2. 기타 피드백은 틈틈이 읽으며 반영하자.

2. Goal

• SOLID 복습 및 TDD, MVC패턴 이해하기
• 커밋 컨벤션 읽기
• camp.nextstep.edu.missionutils의 Random,Console 구조 공부하기
• JUnit 5와 AssertJ 확인
• 테스트 도구 사용법이 익숙하지 않다면 test/java/study를 참고하여 학습

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

• 객체지향 생활체조 & 공통피드백 자주 읽기
• 예외처리 클래스 연습
• Stream Api, 람다식 연습
• Enum 활용 연습
• 접근 제어자 연습
• Java Style Guide 읽기

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

• 깃헙 계속 공부

3. Study for mission

학습 내용

During Mission

Drawing Answer

기능

1. 컴퓨터가 1~9 사이 임의의 서로 다른 수 3개를 선택
   1. Random API?
2. 스트라이크, 볼, 낫싱 리턴
   1. map?
   2. 각 리턴 형식에 맞춰서 출력
3. 정답을 맞추면 게임은 종료.
   1. 종료 후 다시 시작하거나 아예 종료할 수 있다.
4. 시작 문구 출력

요구

1. ‘서로 다른’ ‘3자리’ ‘수’여야 한다.
2. 게임이 끝난 경우 재시작 : 1 / 종료 : 2
3. 출력은 요구 사항에 맞춰서.
4. camp.nextstep.edu.missionutils 의 Randoms 및 Console을 사용한다.

제한

1. 반복 횟수는 제한이 없는 듯.
2. 사용자가 잘못된 인풋을 넣은 경우 IllegalArgumentException을 발생시킨 후 ‘애플리케이션’ 자체는 종료되어야 한다.

Main Idea

기능 구현 목록

solid원칙이든 TDD든 결국 클린코드를 구현하기 위해서는 기능 목록을 작성하며 큰 그림을 완성시키는 것이 좋다고 생각된다. 우선 기능 구현을 완료한 후에 클래스와 메소드, 인터페이스 등을 구상하고 이를 그림으로 나타낸 후에 구현해보자.

내부 클래스와 외부 클래스의 차이점?

Integer.parseInt();

이 메소드는 문자열을 기본형 정수 (primitive type int)로 리턴한다. 문자열이 유효한 숫자를 포함하지 않는다면 NumberFormatException이 쓰로우 된다.

생각보다 TDD방식을 따라하는게 너무 어렵다.

무엇보다 기능 구현 단위를 나누고 그 단위로 커밋하는 습관이 잡혀있지 않아 계속 먼저 구현해버려서 커밋을 나중에 하고 있다. 일단 어쩔 수 없으니 기능구현을 다 한 후에 리펙토링하는 과정에서라도 제대로 다시 해봐야겠다.

After Mission

최종보고서

공부스타일

공부해보면서 느낀 점들이 역시나 많다. 인터넷으로 구글링을 하면서 정보를 찾는 것도 도움이 되지만 결국 프로그램 자체의 코드를 뜯어보는 것이 정도(正道)인 것 같다. 코수다에서 코치님이 말씀해주신 내용중에 인터넷으로 찾아서 공부하다보면 잘못된 지식을 얻는 경우도 있다고 하셨는데 그런 경우를 몇번 당한 것 같다… 차라리 코드 자체를 교과서라고 생각하고, 영어 울렁증 이겨내고, 하나하나 읽어보는 습관을 들여야 할 것 같다.

테스트코드 작성 미스

처음엔 TDD패턴을 최대한 적용하려고 했다. 하지만 Junit5과 AssertJ에 대한 학습이 너무 늦어지고 각종 학업을 병행하다보니 과제 해결에 너무 급하게 돼서 결국 또다시 문제만 먼저 해결해버리고 말았다. 이번 기회를 통해 테스트 코드에 대한 식견과 실력을 어느 정도 기본기는 닦았으니 다음 과제때는 꼭 TDD 스타일로 해보고자 한다.

커밋 단위 및 양식

역시 쉽지 않았다. 커밋 양식은 어느정도 이해했고 맞춰서 하려고 시도했다. 하지만 단위가 문제였다. 기능 구현 목록을 처음부터 엄청 세밀하게 짜지 못해 구현 목록을 계속 세분화하는 일이 많아졌고, 그러다보니 커밋도 조금씩 복잡해지는 느낌이었다. 무엇보다 초기 설계가 부실하다보니 클린코드를 실천하기도 어려웠다. 초반 설계에 전체 시간의 대부분을 쏟아부어도 좋으니 우선 코드를 머릿속으로 쭉 시뮬레이션해보고 최대한 세밀하게 목록을 작성해야겠다고 생각했다.

아직은 어색한 클린코드

숫자 야구 게임이라는 프로젝트를 구현하면서 SOLID 원칙, 객체 지향 등 클린코드를 위한 각종 원칙과 패턴을 적용하려고 노력했다. 그 일환으로 draw.io를 사용하면서 최대한 현재 프로젝트가 어떻게 구성되어 있는지, 기능들은 어떤 식으로 나눠져있는지 정리하면서 나도 모르게 놓치고 있는 코드들은 없는지 하나도 흘리지 않기 위해 노력했다. 그 과정에서 몇가지 수정해야할 내용들이 보여 리펙토링을 수행하였다. 결과적으로 특정 기능에 따라 클래스들을 구분하고 메소드들도 최대한 한 기능만 하도록 하다보니 끊임없이 리펙토링을 하게 되었다. 이 역시 초기 기능 구현 목록을 세분화하지 못해 일어난 일이므로.. 다시 한번 초기 설계의 중요성을 깨닫게 되었다. 무작정 초기 조건만 보고 달려드는 것이 아닌, 문제를 쭉 읽어보며 요구 사항, 조건들을 전부 이해한 다음에 전체적인 풀이 과정을 설계하여 접근해야 하는 것이다. 마치 수학문제를 푸는 것처럼.