우아한 테크코스 6기 프리코스 2주차 회고

요즘 문득 드는 생각이지만 프리코스에 참여하길 잘한 것 같다. 성장하기위해 들어왔지만 회고,소감문이 너무 좋아진다. 회고를 하면 내가 뭘 잘못했는지 인지를 하고 고쳐나가야 할 부분들은 찾고,배워나가며 소감문을 통해서 뭔가 내 마음(?)을 다 담아서 쓸 수 있는 점이 너무 좋은 것 같다. 누군가에게 솔직한 감정을 써서 보여주는게 얼마만인지..너무 좋다.

만약 프리코스가 끝나면..노션에라도 적어야겠다..힘내자 !

2주차 공통 피드백

README.md를 상세히 작성한다

README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서이다

2주차 미션을 받고 기능 명세서 목록 같은 경우엔 1주차 미션에 문서를 가져와 조금 다듬어 사용했다.
추가적으로 넣은 부분은 단위테스트 목록, 예외 테스트 목록을 추가적으로 작성하였다. 예외 테스트는 구현이 다 끝난 이후에 예외테스트목록을 추가적으로 넣었던 것 같다. 옛날부터 이건 그냥 default였던 것 같다.. ㅋㅋㅋ 일단 예외보다 구현이 먼저.. 빠르게..ㅎㅎ

하면서도 테스트에 성공하게되면 체크표시를 해가며 commit을 해왔다. 아 !

위 사진은 1차 그리고 2차 커밋을 나뉜 사진 입니다..아직도 좀 엉성한 감이 없지 않아 있는데 .. 그래도 좀 scope를 넣으니까 괜찮지 않나...? 그냥 자기 합리화인가....?

무튼 갑자기 생각났다...ㅋㅋㅋㅋㅋㅋㅋㅋㅋ(1차 커밋봐 뭔 complete이야..정훈아..그냥 한국말쓰자)

본론으로 들어가면 마크다운 문법으로 여러모로 문서 작성을 사용하게 될 것이니 배우는게 좋다.

MarkDown 몰랐던 부분들

https://www.markdownguide.org/

제목 작성

흔히 제목 작성 같은 경우엔 # 을 붙이면 되지만 MarkDown 공식문서에서는 제목을 쓸땐 제목 이름 사이의 공백을 꼭 주라고합니다. 호환성을 위해 항상 꼭 둬야한다고 하네요 !

https://www.markdownguide.org/basic-syntax/#heading-best-practices

테이블 사용법

| 이름 | 취미 |
| ----------- | ----------- |
| 김떙떙 | 개발 |
| 오옹 | 잠자기;; |

이름	취미
김떙떙	개발
오옹	잠자기;;

머리글 조정

| 이름 | 취미 |
| :----------- | -----------: |  // : 을 통해 정렬 할 수 있다 !
| 김떙떙 | 개발 |
| 오옹 | 잠자기;; |

이름	취미
김떙떙	개발
오옹	잠자기;;

머리글 셀 내 목록쓰기

| 이름      | 취미 |
| ----------- | ----------- |
| 김떙떙      | 개발 |
| 오옹        | 잠자기 <ul><li>언제자 혹시..</li> |

이름	취미
김떙떙	개발
오옹	잠자기 언제자 혹시..

Text Highlight

아 <mark>프로그래밍을 좀 더 빨리 알았더라면</mark>.좋았을텐데

아 프로그래밍을 좀 더 빨리 알았더라면..좋았을텐데

오 신기하다 이건 처음 알았네요

https://www.markdownguide.org/extended-syntax/#highlight

기능 목록을 업데이트한다

README.md 파일에 작성하는 기능 목록은 기능 구현을 하면서 변경될 수 있다. 시작할 때 모든 기능 목록을 완벽하게 정리해야 한다는 부담을 가지기보다 기능을 구현하면서 문서를 계속 업데이트한다. 죽은 문서가 아니라 살아있는 문서를 만들기 위해 노력한다.

뭔가 이 글을 보니까 너무 위안이된다..1차,2차 둘다 README 파일에 완벽하게 작성하고 커밋할려고 했다. 야구장 피드백 영상도 보면 휘리리리릭 휘리리릭 커밋도 딱 간단명료하게 (?) 쓰시던데..그렇게 하고싶은데 잘안된다;;;;;;;;

좀 이상한거는 머리로는 어느정도 어떻게할지 감이 오는데 왜 ... 왜 ?! README를 쓸려하면 1시간동안 붙잡고 있다..진짜 한심해 죽겠다.. 막상 Docs 보면 이게 한 시간 고민 끝에 나온거라고 하는 부분 이겠지만.........!

3차 4차때 조금만 더 틀을 이쁘게 만들어서 템플릿만 유지한채로 계속 구현하면서 Docs를 수정하고 너무 시간 쓰지말자..그냥 차라리 생각나는데로 적고 계속 수정해 나아가면서 하자...제발 부탁이야 (정훈아..)

값을 하드 코딩하지 않는다

문자열,숫자 등 값을 하드 코딩하지 않는다. 상수(static final)로 만들고 역할이 무엇인지 의도를 드러내라 .

분명 static final로 상수로 해놓은 부분들은 많았다. 근데 사용하면서도 알듯 말듯 하면서 쓴 것 같다.

final

final 을 붙여서 사용하면 첫 초기화 이후 재할당이 불가능해진다
```
final int age=26;
age=99; //compile error 
```
메소드에 final을 붙이면 예를들어서 자식 클래스가 부모의 메소드를 오버라이딩이 불가능하다.
- 왜 이거 몰랐지
클래스에 final을 붙이면 부모 클래스가 될 수 없다.

static

static은 전역에서 사용하는 의미이며 static 키워드를 붙여서 사용할경우 데이터의 메모리 할당을 컴파일 시간에 하는 것을 의미한다.
static은 객체를 생성하지 않고 (인스턴스)클래스명.변수명으로 접근이 가능하다.
- static 을 사용하게되면 객체가 생성이 되기전에 static 메모리 영역에 할당이 되기때문에 사용이 가능하다
static 메서드도 동일하다.

static final

static final을 붙여서 사용하게되면 상수라는 의미를 갖게 된다
- 상수는 프로그램이 시작에서부터 종료까지 끝까지 값이 바뀌지않는것을 의미한다.
선언과 동시에 초기화된 값을 프로그램 종료 될 때 까지 가지고 있는다.
인스턴스가 만들어질 때마다 메모리에 초기화되지 않고 하나의 메모리 공간만을 사용함.

처음부터 큰 단위의 테스트를 만들지 않는다

요번 2차에서는 작은 단위의 테스트를 만들었던 것 같다. 이렇게 함으로써 느낀점은 확실히 비지니스로직 보단 설계 및 리팩토링에 조금 더 신경 쓸 수 있었다. 조금 귀찮았고 습관이 되지 않았던 부분이였지만 차근차근 느끼면서 하니까 조금씩 테스트의 중요성을 알게 되었다. 함수를 작게 분리를 했다하면 에러가 터져도 빠르게 함수 기능만을 리팩토링 및 에러를 고치고 테스트를 하면 되는 부분이었기 때문이다.몇번이나 적용해 보았던 테스트코드..항상 별 생각없이 써라해서 썻는데 요번 프리코스를 시작하면서 실제로 함수 기능 문제가 생겼을때 중요성을 느꼈기 때문에 더더욱 중요하다라고 느껴졌다. 이를 토대로 이번 3주차에는 TDD를 도입하여 적용해봐야겠다..!

큰 단위 테스트도 신경쓰자

느낀점

2주차 과제를 시작히기전 mvc패턴에 대해서 학습하고, 일급컬렉션을 적용해 문제에 적용하였다.mvc패턴을 적용하면서 정말 모호하게 생각한 부분들이 있었는데 정말 코드리뷰를 통해서도 댓글이 달렸었다.

쓰면서도 계속 생각이 들었다...이게 정말 맞는말일까 ? 뭔가 mvc패턴은 규격만 정해진 것 일뿐이지 그 안에서 녹여내는건 내 몫이라고 생각했다. 규격과 형태를 잡아주게되면 그 이후에는 서로 결합도가 높아지지 않게 의존하는 것만 덜어내면 충분히 괜찮다고 생각이 들었다(근데 어디까지나 내 생각일뿐 ..계속 공부를 하면서도 내가 이해한 부분은 아닌 것 같다.) 또한 실질적으로 문제에서 주요로 다뤄지는 자동차라는 객체는 필드 변수만 존재하지 어떠한 의존도 받지 않게 RaceCar라는 객체를 일급컬렉션을 사용하여 다뤘다.사용한 이유는 상태와 행위를 한 곳에서 관리하고 싶었다. 제일 어려운 점은 내가 이렇게 하면서도 이게 맞나 싶다..근데 이런걸 해결하기위해 커뮤니티가 있는 것 같은데..뭔가 이 프리코스만큼은 나 혼자 깨닫고 성장하고 싶은 마음을 가지고 프리코스에 참여 하였기 때문에 나와의 약속을 깨기가 싫었다. 그러면서 깨닫는 것도 있고 보기도 어려운 Docs 읽어보려고 노력을 하지 않을까 싶기도하다.특히 회고,소감문 이게 진짜 진국인것같다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
왤캐 쓸때마다 좋은지 모르겠다... 반성하면서 다시한번 돌아보고 배우는...!

하지만 사진속 답장을 하고나서도 다음날까지 고민을 했던 것 같다. 결국이 InputView를 통해서 service가 초기화 할 당시에 의존성을 받고 시작하니까 service는 InputView가 없으면 어플리케이션 자체의 동작이 안될 것 같은 생각이 들어 아래와 같이 코드를 변경했다.

//전 
  public RaceService(InputView inputView) {
      this.raceCar = new RaceCar();
      addRacingCarsFromInput(inputView.racingCarName(inputView.commonFromInput()));
      validateCheckDuplicateCarName(raceCar.getSavedCar());
  }

//후  
 public RaceService() {
     this.raceCar = new RaceCar();
 }

이렇게 후 코드 처럼 하게 되면 의존성 주입을 받는 부분도 없을 뿐더러 컨트롤러에서 View에 데이터를 넘겨주면 되는 것이었다. 이러면 어플리케이션 동작은 하게되는 쓰레기가 되지 않을까 ..?

하지만 이후에도 문제는 되게 많은거 같다.
위 사진의 코드는 서비스인데도 불구하고 View 해당하는 로직이 갑자기 들어와서 급하게 리팩토링을 하였다..하지만 리팩토링하고 푸쉬하는것도 기간이 있어서 커밋이나 푸쉬는 못했지만 혼자 리팩토링을 해본 코드는 아래 와 같다 .

위 코드를 컨트롤러에 옮겼더니 이번엔 Controller의 해당되지 않는 모습이어서 OutView 클래스에서 관리하였다 사진속에 코드는 컨트롤러로 다시 옮긴 이후 모습이다. 하지만 이것도 뭔가 Controller인데 있는게 맘에 안들어서 resultView 메서드를 OutView Class에서 관리하였다. 이후 OutView에서도 또 view가 model을 알고있는게 생기다보니..dto로 변환이후 OutView에서 관리하였다. dto 같은 경우엔 record를 통해 클래스를 추가하였고