Week6 회고

서론

이번 주에는 Front-end와 Back-end가 협업을 하여 한 주 동안 프로젝트를 진행해보는 시간을 갖게 되었다. 간단하게 이번주에 어떤일을 했고 어떤걸 느끼게 되었는지 이야기 해보고자 한다.

본론

1. 코드컨벤션

• 코드의 통일성과 가독성을 위해서 코드스타일은 카멜케이스로 정했다.

• DB모델의 객체는 변수와 구분하기위해 파스칼케이스로 정했다.

  • 스네이크 케이스(Snake Case)

    snakae_case :
    언더바(_)를 사용해 단어의 의미를 구분해준다.

  • 카멜 케이스(Camel Case)

    camelCase :
    첫 글자는 소문자, 두번째 단어부터는 첫 알파벳을 대문자로 표기한다.

  • 파스칼 케이스(Pascal Case)

    PascalCase :
    모든 글자의 첫 알파벳을 대문자로 표기한다.

• 사용이 끝난 console.log()는 바로바로 지우도록 했다.

• 최대한 에러메세지를 에러코드별로 상세히 응답하도록 약속했다.

2. 브랜치 전략

• Git을 효율적이고 체계적으로 사용하기위해 팀원들간 규칙을 정하는것을 말한다.
• 브랜치 생성에 규칙을 만들어서 협업을 유연하게 하는 방법론을 의미하기도 한다.
• 깃 플로우라는것도 있지만 너무 복잡한감이 있고 작은 프로젝트에는 적합하지 않아서 사용하지 않았다.
• 주로 소규모 프로젝트에 사용되는 깃허브 플로우를 사용했다.

Git flow
보이는 것처럼 꽤나 복작한 로직을 가지고 있어서 작은 프로젝트에는 적합하지 않다.

GitHub flow
master 브랜치 하나와 새로운 기능추가를 실험해볼 브랜치를 기능의 이름으로 정하고 사용이 끝나면 지워버리는게 가장 핵심적인 특징이다.
1. master 브랜치로 어떤때든 배포가능하다.
2. 새로운 기능을 시작해보기 위해 브랜치를 master에서 딸때 이름은 어떤기능을 하는지 명확하게 작성한다.
3. 원격 브랜치로 수시로 push한다.
4. 머징 준비가 완료되었을때는 pull request를 생성한다.
5. 코드 리뷰가 끝나면 master로 머지한다.
6. master로 머지되고 푸시되었을때 즉시 배포되도록 한다.

3. API명세서 작성하기

• API명세서는 FE와 BE 모두를 위한 개발자를 위한 문서라고 할수있다.
• API에 대한 요청과 응답을 잘 약속해두고 정의해두어야 혼동이 없으며 개발하기도 편했던 기억이난다.
• 에러메세지도 에러코드별로 상세히 정의해둘수록 서버쪽에 문제가 생긴건지 클라이언트가 요청변수를 실수한건지가 잘 나타나게 된다.

이런식으로 작성을 해보았는데, 처음이라 그런지 어설픈 부분이 분명 있을거같다...

결론

이번주에 처음으로 FE와 BE가 협업을 하면서 호흡을 맞추기위해 API명세서도 작성하고 어떤식으로 json을 응답해드려야 편할지도 고려하는등 협업을 하는데 많은노력과 생각을 자연스레 하게되는거 같았다. FE는 json을 받으면 배열은 map()함수를 돌려서 파싱을 보통 하시므로 비슷한 요소들을 한배열내 요소로 넣어야하고 다른 카테고리라면 절대 한 배열에 추가하는식이아닌 새로운 배열을 만드는식으로 진행해야 한다.