오 늘  할  일

- Querydsl 강의듣기

- Querydsl로 기능 구현


공 부 기 록

 

queryDsl( jpql vs querydsl ~

jpql vs querydsl

jpql - 문자열이여서 사용자가 해당 메소드를 호출했을 때 런타임에러 발생

querydsl - 컴파일시점에 에러 발생 QType을 만들어내서 자바코드로 품

 

컴파일 시점 오류 발생, 파라미터 바인딩을 자동으로 해줌 

 

Q-type

Q클래스 인스턴스 사용하는 2가지 방법

별칭 직접 지정 : QReview qReview = new QReview("r"); -> 같은 테이블을 조인해야하는 경우에 사용

기본 인스턴스 사용 : QReview aReview = QReview.review;

 

결과 조회

fetch - 리스트 조회 , 데이터 없으면 빈 리스트 변환

fetchOne - 단건 조회 - 없으면 null, 둘 이상이면 NonUniqueResultException

fetchFirst - limit(1).fetchOne()

fetchResults - 페이징 정보 포함, total count 쿼리 추가 실행 -> 성능이 중요한 쿼리에서는 사용하면 안됨 최적화한 count 쿼리를 따로 날려 줘야함

fetchCount - count 쿼리로 변경해서 count 수 조회

 

정렬

 


Toongather

오늘의 궁금증

1. dto로 변환 할 때는 service 단에서 하는게 나을 까? repository 단에서 바로 dto 로 변환하는게 나을까?


 

회  고

- Querydsl 강의듣기(완료)

- Querydsl로 기능 구현(x)

 

이번 툰게더 사이드 프로젝트 하면서 순수JPA , Spring JPA, Querydsl 다 사용해보려고 했는데

하면서 욕심이라는 생각이 들어서 ㅋ 이번에는 QueryDsl은 제외한 나머지에 집중해보자는 생각이 들었다 ㅋ

화이팅~

 

 

 

반응형

오 늘  할  일

- JPA 강의 듣기

- 툰게더 조건 별 리뷰 조회 테스트 코드 작성


Toongather

아우 오늘 조건별 리뷰 조회 테스트 코드 작성하는데

별점 높은순, 별점 낮은순은 잘 햇는데 최신순에서  막혔다..

BaseEntity 공통 Entity 사용해서 등록날짜, 수정날짜 넣고 있어서 테스트 코드 작성할 때 리뷰를 작성해서 넣으면 등록날짜가 똑같이 들어가서..

테스트 할수가 없다... 아우 결국 해결 못하고 오늘 마무리 그렇다고 테스트를 위해 굳이 등록날짜 변경하는 기능을 만드는건 좀 그렇고.. 

 

내일 다시 해봐야겠다.


회  고

- JPA 강의 듣기 (x)

- 툰게더 조건 별 리뷰 조회 테스트 코드 작성(세미완료)

 

오늘 업무 바빴는데 그래도 오후에 했다...! 내일은 오늘 못한 테스트 코드 마저 작성해보고 jpql로 작성한 쿼리 Spring JPA로도 작성해봐야겠다.

아자아자~

반응형

오 늘  할  일

- 깃 강의

마무리

- 툰게더 컨벤션 정하기


공  부  기  록

init - 

add - git이 관리할 대상의 파일 등록하기

commit - 버전 만들기

pull -원격저장소 받는 것 

status - 파일 상태 확인:  Untracked(관리대상이 아님) git add 하지 않은 상태   Tracked(관리대상임) : git이 관리하는 파일임을 의미    unmodified : 최근 커밋과 비교했을 때 바뀐 내용이 없는 상태    modified : 최근 커밋과 비교했을 때 바뀐 내용이 있는 상태    staged: 파일이 수정되고 나서 스테이지 공간에 올아와 있는 상태 git add 후 상태

 

git ignore 파일clone 원격 저장소의 코드를 컴퓨터에 받아올 수 잇습니다.

 

branch

 

checkout 

  - 브랜치 이동

   - checkout기능이 많아져서 switch , restore가 도입   

   - switch : 브랜치 이동   

   - restore : 파일 수정 내용 복원과 add를 통해 스케이지에 올린 파일 빼낼 때 사용합니다.

 

브랜치 삭제

브랜치 복구


Toongather

 

오늘 본격적으로 프로젝트 시작 전에 필요한 것들을 정했다.

 

1. 깃 마일스톤, 프로젝트 생성
2. 이슈 규칙 / 템플릿
3. PR 규칙 / 템플릿
4. Branch 생성 규칙 
5. commit 메세지 규칙

 

서로의 의견을 취합해서 결론은

프로젝트 생성, 마일스톤은 매주
이슈제목은 [도메인] + 제목 내용은 만들고 
pr은 작은리뷰로 그리고 이슈 닫을 때 close 문구 쓴다
브랜치 - [상태]/이슈번호 로하구
커밋 - [상태] 제목 , 상세내용 추가할거면 엔터치고 줄 글 로쓰기

 

여기서 커밋 메세지 규칙은 참고1,참고2

위에 사이트를 참고해서 쓰기로함

이슈,pr 템플릿을 생성 시 에디터에 자동으로 양식이 등록 되도록 설정했다.

 

내일부터 본격적으로 기능구현이다~~~ 아자아자~!~!~!~!~!~!


 

회  고

오늘 ㅋ 툰게더 시작 전에 결정할 것들이 많아서 결정 다하고 ㅋ 내일부터 기능 구현이다. 깃 전략, pr, 이슈 템플릿 규칙 등등을 정하니깐

본격적으로 시작하는 것 같아서 ㅋ "두근두근" 거린다 ㅋ 그리고 깃에 좀 익숙해진 느낌 ㅋ 일단 고 하면서 깃 강의는 주말에 마무리해야겠다.

그래도 전반적인 느낌은 알 것 같다.

 

내일은 이슈 만들고 마일스톤 만들고 해서 시작해야겠다 ㅋ 그리고 JPA 실무 강의도 좀 봐야겠다.

 

김영한씌가,, 야생형 개발자가 잘 성장한다고 했는데 왜 그런지 알 것 같은 느낌이다.나는 좀 학자형 타입인데 야생형으로 하니깐 모르는게 와다다다 나와서 하나하나 쳐내니깐 성장한 느낌 ㅋ

 

여튼 오늘도 성장했다~!내일도 화이팅~!


 

내 일  할  일

- JPA 실무 강의 듣기

- 툰게더 이슈, 마일스톤 생성

- 기능구현

 

 

오늘 TIL 끝!

반응형

오 늘  할  일

- git 강의 듣기

 

공 부 기 록

팀 구성 후 뭘 해야할까?오거나이제이션 하면 좋다 -> 누군가 레포지토리 private 처리할 수도 있고..

 

툰게더 시작 전 같이 얘기해 볼 것

1. 깃 프로젝트 생성해서 todo 관리해보는 거 어떤지

2. 이슈랑 PR 템플릿

3. 기능 브랜치 컨벤션 정하기

 

PR- 리뷰어 지정해서 승인받을 수 있음.- 최대한 상세하게 적어야 함, 그들은 자기 업무도 보면서 리뷰해 주는 거기 때문에- 브렌치 삭제할 수도 있음

 

CI/CD 자동배포 구축은 action을 통해 할 수 있음. wiki -> 나중에 프로젝트 문서 작성 

 

깃 - 소스코드 및 파일의 변경내역을 저장하는 분산 버전 관리 도구

깃허브 - 커밋 : 로컬 저장소에 변경내역을 올리는 것

 

 

회  고

- git 강의 듣기(완료)

 

처음 stash 써봄 ㅋ master 브랜치로 체크아웃하려고 했는데 수정된 파일 2개 stash 해서 잠깐 임시저장 해놓고 review 브랜치랑 병합했다.

깃 공부하면서 내가 모르는 걸 배우기 전에 두려움? 이 컸던 것 같다. 막상 배우면 별 거 아닌데 그냥 편하게 하기 위한 도구일 뿐이다.

그리고 모르면 물어보면 된다 ㅋ "두근" 이제 모르면 두근거리고 설레는 마음을 갖도록 해야겠다...!!!

내일부터 툰게더 기능 구현 다시 시작하는데 화이팅~! 이다!!

 

 

내 일  할  일

- 출근하면서 깃 강의마저 듣기

- 툰게더 기능 구현 시작 (TIL 적으면서 상세하게)

 

 

반응형

오 늘  할  일

- 깃 이슈 & pull request

- 깃 강의 듣기

깃 이슈 & pull request

fork

fork: 소프트웨어 개발 포크, 프로젝트 포크 개발자들이 하나의 소프트웨어 소스코드를 통째로 복사하여 독립적인 소프트웨어 개발하는 것을 말한다.

 

Pull Request

fork한 리포지토리에 기능을 추가하고 원본 저장소에 기능을 반영하고 싶을때 요청 하는 것

원본 저장소의 권한을 가진 사람에게 두 브랜치를 합치는 것을 허락해 달라고 요청을 보내야함

* 협업 시 최대한 직접 merge 하는 것은 피하고 모든 merge를 pull request를 통해서 하는 것이 좋음

→ 상대방이 PR을 보고 코드 리뷰가 가능하기 때문입니다. 수정이 필요하면 댓글을 달아 change request를 보낼수 있음.

    단, 오픈소스에 PR 보낼시에는 기여 안내문서를 참고해야한다.

 

** 풀 리퀘 왜 하나 했음 그냥 merge 하면 되는거 아닌가 근데 같이 코드리뷰 하고 그래서 그렇구만...

 

참고

 

이슈 & PR 템플릿

이슈 템플릿 설정 방법

 Setting -> Features 이슈탭 > set up templates

.git <- 폴더에서 확인 가능

PR 템플릿 설정 방법

레포지토리 -> add file -> create...

pull_request_template.md <- 파일 생성

참고 

https://velog.io/@pikadev1771/Github-%EC%9D%B4%EC%8A%88-%EB%A7%88%EC%9D%BC%EC%8A%A4%ED%86%A4

 

사이드 프로젝트 - 툰게더

이번에 툰게더 다시 시작하면서 디스코드로 만나서 회의했는데 얘기하면서

모르는 것 천지여서 시작전에 공부좀 하려고 한다 ㅋ 깃 브랜치를 원래 도메인 별로 땄다가 이번에 

회사에서 svn 사용해서 기본 기능만 알고 있었어서. 공부 시작 ㅋ 설날 동안 심심한데 잘걸렸다 ㅋ

 

 

회  고

이 날 친구들하고 파티가 있어서 ㅋ 회고 못쓰고 끝~

 

내 일  할  일

 

 

 

 

반응형

오 늘  할  일

- 테스트 코드 강의 듣기

 

테스트 코드  강의 기록

테스트 코드는 왜 짜는가?

 

자동화된 테스트 vs 수동테스트

- 자동화된 테스트란 무엇이고 뭘 비교할 것인가? 중요할 것 같다.

- 조회는 뭐 어케 테스트하지? 보통 안하나?

오옷 올바른 테스트 코드는 무엇인가

테스트 코드는 왜 짜야 하는 것인가?

 

단위테스트

- 작은 단위에 독립된 테스트 / 메소드, 클래스 단위 (네트워크연동x)

Junit5 - 단위테스트를 위한 테스트 프레임 워크 

AssertJ - 테스트라이브러리, 풍부한 api, 메서드 체이닝 지원

 

테스트 케이스 세분화하기

- 해피 케이스 

- 예외 케이스 

경계값 테스트..?가 중요하다.

 

테스트하기 어려운 영역을 구분하고 분리하기

- 항상 맞는 테스트가 아님 -> 시간 관련해서는 시간을 외부에서 넣어줌 해피 / 예외 분리함 

- 테스트 불가능한 부분이 테스트가 성공했다가 실패했다가 -> 테스트 하고자 하는 영역 

 

테스트하기 어려운영역: 관측할 때마다 다른 값에 의존하는 코드(IN)

→ 현재날짜/시간, 랜덤값,전역 변수/함수, 사용자입력 등

외부 세계에 영향을 주는 코드(OUT)

→ 표준 출력, 메시지 발송, 데이터 베이스에 기록 등

 

테스트하기 쉬운(순수함수)

 

TDD(Test Driven Development)

- 테스트 주도 개발

사이클 : 레드 - 그린 - 리팩토링

 

선기능구현, 후테스트 작성

: 누락가능성 / 특정 테스트 케이스만 검증 / 

 

선테스트 , 후기능구현

: 테스트와 상호작용하며 발전하는 구현부 / **피드백 

클라이언트 관점에서의 피트백을 주는 Test Driven

 

** 예외에 대해서 

회  고

  - 테스트 코드 강의 듣기(TDD까지 완강)

 

인강 들으면서 어떻게하면 의미있게 테스트를 짤수 있을까?라는 생각을 제일 많이 한 것 같다.

지금 듣는 건 넓게 알려주는 스타일 인 것 같은데 관련 서적 찾아서 읽어봐야 할 것 같다.

 

이때까지 짠 테스트 코드는 자동화가 전혀 안되어있었음 자동화라는 개념도 없었구만 ㅋ

하나 배웠다 ㅋ

내 일  할  일

- 테스트 강의 보기

- 툰게더 커밋하기

 

 

반응형

+ Recent posts