tdd( test driven development)

1. 단위테스트(개별api를 테스트함)

2. 통합테스트(api들의 묶을을 테스트함)

3. e2e test(진짜 유저가 사용한다고 가정하고 로그인부터 결제까지 테스트함)

test파일은 test또는-spec이라는 단어가 붙어있다.

1. 기능명세서 -> ERD -> api명세서 -> sequance 다이어그램(외부에서 데이터 검증, 트랙젝션 등 여러 복잡한 단계가 필요한 api는 어떤 순서로 작동될지 정해야한다)

프로젝트 설계 => 깃허브 협업(깃플로우 워크플로우) =>

처음엔 엑셀이나 a4용지를 가지고 api명세서를 짜고 그것을 토대로 erd를 구상한다. -> erd구상을 erd-cloud

과제: 어떠한 api를 만들어야 할지 어떤 포인트를 잡고 만들어야 할지 공부해보자

git

git branch -> 현재 브렌치를 알려줌

git checkout -b fetchBoard -> 현재 브랜치에서 fetchBoard라는 브랜치로 옮겨줘라 (-b는 없다면 만들어서 옮기라는 뜻이다)

--> 각 기능마다 필요한 기능들은 feature-<기능명> 에서 작업하고 작업이 완료되면 dev라는 브랜치에다 합쳐준다.

--> 기능들이 어느정도 합쳐져 더이상 기능개발이 끝났을때 배포 작업을 위해 release 브랜치에 올린다. (release에서는 기능 추가는 끝나고 버그만 수정한다.)

--> 버그 수정이 완료되면 master 브랜치로 올려 서비스화 한다.

--> 만약 master로 배포하고 서비스 사용중에 중대한 버그가 발견됫을시 hot-fix브랜치로 가져와 버그 수정후 다시 master로 옮겨서 배포한다

git (fork)

-> 메인 브랜치가 있을 경우 개발자들은 메인 브랜치에서 작업하는것이 아니라 복사를 해와서 본인의 워크스페이스에서 작업을 해야한다. 이때 메인 브랜치의 소스코드를 자신의 저장소로 가져오는것을 포크(fork)라고 하고 fork해온것을 Clone하면 사본화 할수있다.

--> 클론하여 작업을 마치면 각 개발자들은 본인의 저장소(레포지토리)에 add commit을 하여 올리고 각 저장소에서 자신들의 코드를 메인 젖장소에 올리기 위해 메인 저장소(레포지토리)에 pull request(PR)을 한다(merge request)라고도 한다.

--> PR을 올리면 메인레포지토리가 각각의 소스코드를 확인하고 PR을 받을지 말지 결정해서 거절할수도 수용할수도있다.

--> 최신화를 위하여 일단 메인 레포지토리에 소스코드들을 pull하고 그다음 작업을 시작하면 된다.

• 각 개발자가 자신의 레포지토리에 올릴때 자신의 저장소는 origin이라고 하여 origin에 push하지만 pull request는 upstream으로 올린다. upstream은 메인 저장소를 뜻하며 메인저장소의 내용을 pull 받을때는 git pull upstream <메인 저장소 이름> 하여 최신화 하면 된다.

--> git branch -d <브랜치명>: 해당 브랜치를 삭제한다.

• commit convention
  

--> git push origin <자신이 일하고 있는 branch>

회사의 작업 프로세스

1. 회사가 아침에 모두모여 스크럼미팅을 위하여 모인다
2. 어제 올렸던 PR을 코드리뷰하여 메인저장소에 머지할지 말지 결정
3. 각자 자기 자리로 돌아가 upstream에 있는 코드를 pull하여 최신화하기
4. 최신화된 브랜치에서 feature branch 만들고 기능개발하기 -> 각자 해야할일은 스크럼 미팅에서 지정된다.
   5.기능개발이 끝났다면 origin에 push하고 upstream에 PR날린다.
   6.또 해야할일이 있다면 다시 upstream에서 pull받아 최신화 하고 feature branch만들고 기능 개발시작.

포트폴리오 작성법