Git 전략을 세워보자 !!
Git을 기능별로 나눠야 된다....
1단계. 누가 이 작업 할 것인지 정한다. - Issue
2단계. 각자 맡은 것을 작업한다. - Branch
3단계. 각자 작업을 프로젝트에 합친다. - merge
(경우에 따라). 작업한 내용을 리뷰하고 최종적으로 프로젝트에 반영한다. - PR 후 merge
깃에서 Issue에 커밋 #1한걸 인식해서 보여준다.!!
Merge 시 병합할 대상에 체크아웃(예로들면 메인브런치 선택)하고
나온 브런치와 병합..
깃전략에 대해 좋은 기술 블로그 !!
https://techblog.woowahan.com/2553/
+++깃 푸쉬시 본인 브런치에만 푸시가 가능하다!!
다른곳에 푸쉬는 곧 풀리퀘스트 (변경점 적용) 이다!!
+++ 검색 팁
- 인터넷으로 추가 정보 얻기
- 수업 맨 첫 시간에 더 알고 싶으면 인터넷 찾아보면 된다는 거 기억나시나요? 개발자들은 구글링을 많이 합니다!
- 프로그래밍은 문제 해결! 문제해결하기 위해 어떻게 정보를 활용하고 연결시키느냐 중요합니다!
- ❗️구글링이 무엇인가요?
- 여러분이 모르는 것, 전 세계 사람들 다 모릅니다. 이럴 땐 필요한 건 구글! 구글에 검색한다고 해서 구글링(Googling) 이라고 합니다.
- 궁금한 것들을 검색해보면 됩니다. 기술(도구 이름) + 단어 조합으로 하면 훨씬 더 좋은 검색 결과를 얻을 수 있어요. 예.
sourcetree branch - 검색어 팁
- 아래처럼 검색어를 조합해 입력해보세요!
- 기술을 처음 배우고 싶을 때 : '기술이름' + 'tutorial' (예.
git tutorial) - 기능을 찾을 때 : '기술이름' + 'how to' + '찾을 내용' (예.
git how to merge) - 어떻게 사용하는지 예제를 보고 싶을 때 : '기술이름' + '내용' + 'example' (예.
github flow example) - 원하는 사이트명 포함해 검색할 수도 있습니다. (예:
stackoverflow git merge- stackoverflow 라는 사이트에서 검색)
- 검색 결과 중에, 좋은 자료 고르기
- 좋은 자료를 찾으려면 경험치가 필요해요. 많이 검색해보면 자연스레 나만의 검색 노하우와 자료 판단하는 눈이 길러질 거에요.
- 해결책뿐만 아니라 문제(에러)의 이유까지 적어두어서 내 문제와 같은지 판단할 수 있는 정보를 제공하는 글
- stackoverflow - 개발 QnA 사이트입니다. 전 세계적으로 많이 쓰입니다. 질문과 답변, 댓글에 사용자들이 vote 할 수 있어요. 좋은 질문과 답변에는 vote 수가 높습니다.
!!! 백엔드, 프론트 엔드 협업에 관해서
API명세서를 잘 짜야된다... ( 안바뀌는게 좋기때문)
일의 순서가
백앤드+ 디자인 )) -> 프론트엔드)) 이기때문에
프론트엔드는 API명세서를 보고 만든다.
그래서 백엔드쪽은 응답을 줄때 변수 명,타입 및 에러발생시 코드를 보내도록 설정할 수 있다. ..
- JPA 연관관계에 대해서
Many to Many는 어렵다...(휘림님 발표아이디어 참고)
단방향을 지양하고 양방향을 써라!!!
양방향 연결관계
ex)ONE 코멘트 MANY SUB코멘트
java mappedBy 에 대해서
Data table에 없는 테이블을 불러옴
객체이름을 잘써야됨..
- 오직 주인만 FK를 관리한다.(MANY쪽) JoinCoulm 기입
- 주인이 아닌 곳에서는 mappedBy기입으로 주인을 명시해야한다.
- Owner
그럼 주인은 어떻게 정하는 게 좋을까. 김영한 강사님의 팁은 다음과 같다.
- FK가 있는 곳을 주인으로 한다.
- 객체의 개념에 따라서 Team의 members에도 member를 추가하고, member에도 team을 추가하는 식으로 양쪽 다 삽입하는 것도 실수를 줄이기 위한 방법이다.
- 설계는 단방향으로 하되, 반대로 접근이 필요해진 곳에 양방향을 추가하는 식으로 코드를 작성한다.
https://kok202.tistory.com/138
!! 캐스케이드에 관해서
https://data-make.tistory.com/668
https://velog.io/@max9106/JPA%EC%97%94%ED%8B%B0%ED%8B%B0-%EC%83%81%ED%83%9C-Cascade
** orphanRemoval = true
@OneToMany(cascade = {CascadeType.ALL}, fetch = FetchType.EAGER, orphanRemoval = true)
보통 1:N 관계 테이블 설정할때 저렇게 옵션을 추가해준다.
자식 엔티티의 변경이 있다면
JPA 에서 자식엔티티의 수정은 insert update update delete 순으로 이어지는데
변경된 자식을 먼저 insert 하고
기존의 자식을 NULL로 update 한다.
그리고 orphanRemoval 옵션을 true 로 하면 기존 NULL처리된 자식을 DELETE 한다.
PK(JoinColumn)값이 NULL로 변한 자식은 고아객체라고 하여 연결된 점이 없는 객체이다.
orphanRemoval옵션은 바로 이 고아객체를 삭제해주는 역활을 한다.
출처: https://dev-elop.tistory.com/entry/JPA-orphanRemoval-용도 [현직개발자:티스토리]
EAGER(즉시로딩), LAZY(지연로딩) --->>> 패치조인에 대해서
즉시로딩은 현업에서 거의 안쓴다. 왜냐 모두 끌어 오기 때문
지연로딩은 해당 객체를 들고오고 필요할때 get.~~을 쓴다.
LAZY + 패치조인을 같이 쓰면 좋다..
Mypage를 db에 저장하는 건에 관해서
Mypage는 repo를 안만들어도 된다>?? ㅇㅇ
신뢰성문제.... / api를 입력할때 연동된다면 문제 생길수도..
패러다임 불일치...?
내일 검색을 해보자
- AOP를 쓰는이유에 대해서 검색
- 트랜잭셔널 쓰는 이유에 대해서 검색..\
안정상 이유 / db적용되기전 영속성컨테스트
- Bean에 대해 검색....
- 디버깅을 통해서 jwt, filter, 흐름을 파악하자..
