요즘 문득 드는 생각이지만 프리코스에 참여하길 잘한 것 같다. 성장하기위해 들어왔지만 회고,소감문이 너무 좋아진다. 회고를 하면 내가 뭘 잘못했는지 인지를 하고 고쳐나가야 할 부분들은 찾고,배워나가며 소감문을 통해서 뭔가 내 마음(?)을 다 담아서 쓸 수 있는 점이 너무 좋은 것 같다. 누군가에게 솔직한 감정을 써서 보여주는게 얼마만인지..너무 좋다.
만약 프리코스가 끝나면..노션에라도 적어야겠다..힘내자 !
README.md는 소스코드에 앞서 해당 프로젝트가 어떠한 프로젝트인지 마크다운으로 작성하여 소개하는 문서이다
2주차 미션을 받고 기능 명세서 목록 같은 경우엔 1주차 미션에 문서를 가져와 조금 다듬어 사용했다.
추가적으로 넣은 부분은 단위테스트 목록
, 예외 테스트 목록
을 추가적으로 작성하였다. 예외 테스트는 구현이 다 끝난 이후에 예외테스트목록을 추가적으로 넣었던 것 같다. 옛날부터 이건 그냥 default였던 것 같다.. ㅋㅋㅋ 일단 예외보다 구현이 먼저.. 빠르게..ㅎㅎ
하면서도 테스트에 성공하게되면 체크표시를 해가며 commit
을 해왔다. 아 !
위 사진은 1차 그리고 2차 커밋을 나뉜 사진 입니다..아직도 좀 엉성한 감이 없지 않아 있는데 .. 그래도 좀 scope를 넣으니까 괜찮지 않나...? 그냥 자기 합리화인가....?
무튼 갑자기 생각났다...ㅋㅋㅋㅋㅋㅋㅋㅋㅋ(1차 커밋봐 뭔 complete이야..정훈아..그냥 한국말쓰자)
본론으로 들어가면 마크다운 문법으로 여러모로 문서 작성을 사용하게 될 것이니 배우는게 좋다.
흔히 제목 작성 같은 경우엔 #
을 붙이면 되지만 MarkDown 공식문서에서는 제목을 쓸땐 제목 이름 사이의 공백을 꼭 주라고합니다. 호환성을 위해 항상 꼭 둬야한다고 하네요 !
https://www.markdownguide.org/basic-syntax/#heading-best-practices
| 이름 | 취미 |
| ----------- | ----------- |
| 김떙떙 | 개발 |
| 오옹 | 잠자기;; |
이름 | 취미 |
---|---|
김떙떙 | 개발 |
오옹 | 잠자기;; |
| 이름 | 취미 |
| :----------- | -----------: | // : 을 통해 정렬 할 수 있다 !
| 김떙떙 | 개발 |
| 오옹 | 잠자기;; |
이름 | 취미 |
---|---|
김떙떙 | 개발 |
오옹 | 잠자기;; |
| 이름 | 취미 |
| ----------- | ----------- |
| 김떙떙 | 개발 |
| 오옹 | 잠자기 <ul><li>언제자 혹시..</li> |
이름 | 취미 |
---|---|
김떙떙 | 개발 |
오옹 | 잠자기
|
아 <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 int age=26;
age=99; //compile error
오버라이딩
이 불가능하다. 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
를 통해 클래스를 추가하였고
OutView는 resultView
라는 메서드를 두어 해결하였다.
계속 고민하고 고민하다보니 어느새 조금씩 패턴에 이해를 하면서 다가가는 느낌이 들었지만 아직도 뭔가 부족한것같다...하아 그래도 원칙들을 준수할려고 노력하면서 내 스스로가 변할려는 모습이 느껴지는게 참 좋은 것 같다. 3주차 미션도 잘해보자아!