1. 원래는 데스크톱 어플리케이션용으로 고안

MVC

1, Model: 모델은 뷰가 렌더링하는데 필요한 데이터

2. View: 웹어플리케이션에서 뷰는 실제로 보이는 부분. 모델을 사용해 렌더링 (jsp등으로 결과를 표현)

3. Controller: 사용자의 액션에 응답하는 컴포너트, 컨트롤러는 모델을 업데이트하고, 다른액션을 수행

출처: https://www.boostcourse.org/web326/lecture/58979?isDesc=false 

https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html

https://webdevtechblog.com/spring-mvc-architecture-236235d48fa1

1.  사실

1. 코드숨 과제를 완수하지 못했다. (매일 pr을 날렷음에도 불구하고)
2. 알고리즘 문제 4문제를 품
3. 테스트 코드에 대해 고민을 해봄
4. DI에 대해 계속 공부를 해봄

2. 느낌 & 생각들

1. 테스트 코드를 작성하면서 너무 찝찝하다.
2. 내가 과연 비교우위가 있는 개발자인가?
3. 면접에 갔을때 매력적인 개발자일까?
4. 일하고 싶은 개발자일까?
5. 스프링에 들어가면서 먼가 모르는게 너무많아서 약간 숨막히는 느낌.

3. 배운점

1. 결국 취업에 성공하려면 매력적인 개발자가 되어야한다.
   1. 그러기 위해서는 단순히 부족한 것을 채운다는 느낌이 아니라, 더 나아가 그 무엇(?)을 향해서 공부를 해야한다.
2. 찝찝할떄는 고민하기 보다 일단 질러보자. 일단 찝찝하게 작성하고 개선하는 것이 좀더 치열하게 고민하는 거고, 좀더 좋은 퀄리티의 코드가 나올 것이다.
3. 주간 회고를 좀 더 잘해야하면, TIL 나아가 HIL을 작성해야한다. 

4. 확언

1.  매력적인 개발자가 되기 위해. 코딩하면서 깨달은 것들을 정리해보자
2. 일단 선 코드 후 개선.
3. 진짜진짜 til, hil 작성 --> 그래야 더 좋은 주간회고 --> 더 좋은 깨달음 체화

Facts (사실, 객관)

코드숨 2주차가 지났다.

1. 스프링을 처음 써봤다.
2. 스프링에 대한 이론강의를 수강함과 동시에 코드숨 강의 및 과제를 진행하였다.

Feelings (느낌, 주관)& Findings(배운점)

1. delete request의 response가 왜 200이 아니라 204인지 궁금했음.
   --> 지워줘 요청에 대한 대답이 ㅇㅇ 지웠다 가 아니라 no contents 인것이 어색했기 때문
   -->
   rfc7231:

"If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action will likely succeed
but has not yet been enacted, a 204 (No Content) status code if the
action has been enacted and no further information is to be supplied,
or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status."

공식문서에 기준이 이미 있었다.

1. 다양한 예외에 대해 핸들링하라는 피드백이 있었다
   -->아직 스프링을 잘다루지 못하고, 이전에 한번도 해보지 못했던거라 일일히 검색해가면서 해봄.
2. javadoc에 대해 배웠음
   --> javadoc은 모든 사람이 볼것이라고가정하고 써야함
   --> 써머리부분은 한줄로 잘요약해야하고
   --> 파라메터 설명하는 부분들은 명사형으로 간단하게
3. gradle.build 추가하는 것은 깃 커밋에 간단하게 설명해줄것
4. 먼가 자꾸 큰그림을 못그리는것같아서 약간 조급(?)한데 조급하지 말자.
   어차피 코드숨에서 객체지향 설계배우는 주에 아마 뼈가 발려가며 피드백을 받을테니(?)

체크리스트(1주차+2주차)
1. 예외인경우를 빠르게 종료시키고, 가장아래에는 코드의 목적을 위치시킬것
2. 매직 리터럴 주의하기. 최대한 의미가 드러나도록 추상화할것.
3. 코드를 잘짠다의 두가지 기준. 효율성과 가독성.
4. 정적상수는 대문자로 할것
5. 변수이름의 타입을 명시하지 말것.
6. 줄임말 왠만하면 쓰지말것
7. 자바 변수이름은 카멜케이스
8. 확장성 잇는 것을 항상 명심할것.
9. 커밋한번 하고, 오타 등등 확인할것
10. 예외 처리 꼼곰히 해줄것
11. javadoc 잘 써줄것.

이번주 잘한점
의미단위 커밋--> 만족스럽게 함

다음주 꼭 하고 싶은것.
뽀모도로 학습법

Affirmation(자기 선언)

매일매일 til쓰기
--> 아예 시간을 빼놓자

# Facts (사실, 객관)
코드숨 1주차가 지났다.
나의 코드들에 대한 날 것 그대로의 피드백을 받았다.



# Feelings (느낌, 주관)& Findings(배운점)
1. 커밋하고 나서 똑같은 실수를 자꾸 발견한다.
--> 한번 체크하고, 수정하고, 한번만 더 체크하자.
!youtube[Tr0cUGXDVis]

2. 먼가 피드백 받은 거에 급급해서 큰그림을 못그리는 느낌이었다.
--> 큰그림에 대한 고민을 하는 시간을 갖고, 피드백을 받도록 하자

3. 의미단위 커밋을 하는 것을 까먹고, 2개의 의미단위 커밋을 할때가 있다.
--> 미리 계획을 하고 코딩을 하자.

4. 피드백 받은것을 까먹을 것같다.
--> 피드백 받은것을 바탕으로 체크리스트를 만들고, 체크리스트 확인후 코딩을 하도록하자

5. 머 한것도 없는데 자꾸 바쁜 느낌...
--> 중요도를 설정하고 우선순위가 높은것에 충분한 시간을 투자하자.


--------
체크리스트
1. 예외인경우르 빠르게 종료시키고, 가장아래에는 코드의 목적을 위치시킬것
2. 매직 리터럴 주의하기. 최대한 의미가 드러나도록 추상화할것.
3. 코드를 잘짠다의 두가지 기준. 효율성과 가독성.
4. 정적상수는 대문자로 할것
5. 변수이름의 타입을 명시하지 말것.
6. 줄임말 왠만하면 쓰지말것
7. 자바 변수이름은 카멜케이스
8. 확장성 잇는 것을 항상 명심할것.


# Affirmation(자기 선언)
매일매일 til쓰기,
좀더 계획적으로 살기.