210707(수) - Git 전략, 기획, API 논의 및 초기 세팅

1. 팀 Git 전략 수립 (프론트 + 백)

2. 기획 재논의 (프론트 + 백)

3. API 구조 논의 (프론트 + 백)

4. 초기 설정 (프론트)

---

팀 Git 전략 수립 (프론트 + 백)

규칙

• (Branch) main - develop - feature/social - feature/frontend 와 같은 형태로 브랜치 따기
• (Branch) feature 브렌치는 나중에 지운다
• (Issues) 라벨은 프론트엔드, 백엔드 붙이고 뒤에 작업(docs, feature, fix 등 관련된 것들) 붙이기
• (Issues) 프론트엔드, 백엔드 공통이면 라벨(프론트엔드, 백엔드) 붙이지 않기
• (Issue 및 PR) 등록할 때 관련 있는 사람 할당하기
• (Projects) 데모 데이 기준으로 생성하기 -> 앞으로 demo-2, demo-3은 날짜에 맞게 생성할 예정
• (Projects) Projects에서 Card(To do, In progress, Review, Done)이 push 단위랑 꼭 같이 가는 것은 아니다 -> 이것도 일단 해보면서 익혀갈 예정
• (Commit) angular convention에 나와 있는 것을 사용하고, 명사형으로 끝나며, 마지막에 .을 붙이지 않기

추후 논의

• merge 할 때 룰과 같은 설정은 좀 더 익숙해지면 할 예정
• issue는 일단 API 기준으로 진행할 예정

기획 재논의 (프론트 + 백)

디자인에 대한 백엔드 피드백

로그인과 로그아웃 했을 떄 위치가 바뀌는 게 어색하다 -> 통일성을 두는 게 어떨지

로그인 후와 로그인 전 왼쪽 메뉴바 비교

글쓰기를 할 때 위에 있던 설문조사 형식의 방식도 괜찮은 방식같다 -> 이렇게 하면 왠지 글을 짧게 쓸 것 같다는 피드백도 있었다

글 작성에서 인터랙션이 발생하는 방식

기획 확정

사용자가 게시판에서 여러 번의 글을 쓸 수 있는지, 한 번만 쓸 수 있는지 논의가 있었다. 여러 번을 쓰게 된다면 기존에 글 작성에서 인증용으로 첨부된 사진 첨부 기능이 필요하지 않게 된다고 생각했다. 일단 사용자가 게시판에서 여러 번의 글을 작성 할 수 있게 하자는 쪽으로 결정되었는데, 백신을 맞고 어제까지는 몸 상태가 괜찮았다가 오늘은 또 이상한 경우 글을 업데이트하기 위해서 예전 글을 찾는 플로우가 어색했기 때문이다.

또한 신뢰도 문제가 여전히 해결하기 쉽지 않았다. 일단 결론적으로 우리 팀에서 백신 접종을 한 사람인지 완벽하게 거르는 방법은 없었다. 지난 문의 결과도 그렇고 API를 구할 수 없었기 때문이다. 그래도 우리 애플리케이션에서 1차적으로 확인할 수 있는 방법이 인간지능을 이용한 방법이었다. 기존에 비둘기 사진으로 인증해도 인증 성공이 되었지만, 인간지능을 통해 인증 사진이 아닌 사진 등은 거르기로 했다. 하지만 여전히 조작된 사진은 거를 수 없다는 단점이 있기는 했다. 다른 의견으로는 우리가 너무 신뢰도를 높여서 생각하는 것 아닌가 하는 의견도 있었고, 사용자가 인증을 제출하는 곳은 결국 블랙박스여서 사용자끼리 서로 아무 사진으로 인증 성공했다는 게 공유되지 않기 때문에 이 부분에서 그래도 신뢰성을 가져갈 수 있지 않냐는 의견이 있었다. 이 의견에 동의했던 이유로 챌린저스 등 결국은 사용자에게 양심을 맞기고 있는 앱이 있다 등이 있었다. 결론은 '인간지능으로 백신 접종 사진은 맞는지' 정도만 거르기로 했다.

또 깊은 논의를 했던 주제는 인증한 사람만 글을 쓸 수 있느냐였다. 이와 대립한 의견은 로그인만 해도 글을 쓸 수 있다라는 의견이었다. 전자의 경우 우리 애플리케이션의 색깔을 더 강하게 가져갈 수 있다고 생각되었다. 하지만 서비스라는 게 결국은 사용자를 위한 것인데, 사용자가 로그인을 하고 거기에 마이페이지에서 백신 인증까지 해야 하는 게 진입장벽이 너무 높다는 느낌을 줬다. 결정은 아무나 무제한으로 글을 쓸 수 있고, 그 사람들 중에서 인증한 사람은 뱃지 있도록 한다로 결정됐다.

API 논의 (프론트 + 백엔드)

메인페이지, 게시판 메인 페이지 API

글 작성 모달 API

게시판 상세 페이지 API

일단은 다음 데모데이까지 닉네임의 중복(네이버 로그인의 주모, 카카오 로그인의 주모)은 생각하지 않겠다. 또한 일정적인 부담이 있따면 네아로 등을 직접 붙이지 말고 클릭하면 그냥 요청을 보내는 방식을 이용하기로 했다.

메인 페이지의 백신 퍼센트 표시 부분도 일단은 사진으로 할 계획이다 (그래프는 컴포넌트로 하는데, 아무 값을 넣든지)

초기 설정 (프론트)

npm vs yarn

npm은 자바스크립트 런타임 환경인 Node.js의 기본 package manager. 세계 최대의 패키지 저장소이면서 압도적인 자료와 커뮤니티를 기반으로 거대한 생태계가 구축되어 있다. yarn은 페이스북에서 제작한 자바스크립트 패키지 매니저로 다운받은 패키지 데이터를 캐시에 젖아해서 중복된 데이터는 다운로드하지 않는다. 캐시에 저장된 데이터를 활용해서 패키지를 설치하는 속도가 빠르다.

npm의 생태계가 크지만 프로젝트를 진행하면서 필요한 패키지가 yarn에 없을 정도로 비교되는 정도는 아니라고 판단했다. 속도 측면에서도 강점을 굳이 포기하고 싶지 않아서 yarn으로 결정했다.

snowpack vs from scratch

프로젝트에서 cra를 사용하지 못하는 제약이 있는데, snowpack을 사용할 수 있다고 해도 사용하지 않는 게 의도한 부분에 맞다고 생각헀다. 또한 snowpack의 정보가 많은 편이 아니라서 특별히 snowpack을 사용함으로써 얻는 이득이 크다고 생각하지 않았다. 이런 이유들로 처음부터 세팅을 진행하기로 결정했다.

typescript vs javascript + propTypes / react

사실 typescript의 장점은 분명하다. 실무에서 사용될뿐만 아니라, 프로젝트가 커졌을 때 타입을 체크하는 기능만으로도 충분히 편리하고 느낀다. 그리고 애플리케이션을 만드는 과정에서도 더 견고한 애플리케이션을 만들 수 있다고 생각한다. 하지만, typescript를 선택하지 않은 이유도 개인적으로 가볍다고 생각하지 않았다. typescript를 지난 미션에서 한 번 사용해보면서, 올바른 타입을 찾아가며 지정하는 부분 등 코드를 짜기 위해 또다른 노력이 필요하고 느꼈다. 또한 코드를 짠다고 하더라도 돌아가는 애플리케이션은 만들 수 있지만, typescript를 제대로 사용하여 올바른 방식의 타입 추론이 되게 하는 게 쉽지 않았다. 이런 상황에서 앞으로 약 일주일 뒤에 발표하는 데모까지는 일정을 맞추기에는 제약이 있다고 생각헀다. 즉, 언어에 대한 숙련도, 프로젝트 일정 등을 고려했을 때 typescript보다는 javascript를 선택하기로 결정했다. 결국 javascript를 선택하기로 결정했고, 하지만 javascript에서 데이터 등을 주고 받을 때와 같이 타입과 관련된 부분은 확인하기 어렵다는 것에 크루와 나 모두 동의하여 propTypes를 사용하기로 했다. 라이브러리는 react를 선택했다. vanila javascript를 사용하거나 다른 라이브러리나 프레임워크도 선택지가 될 수 있었지만, 먼저 순수 자바스크립트를 쓴다면 보편화된 방식이 없어서 크루와 논의를 처음부터 모든 것을 다시 해야했다. 또한 다른 프레임워크는 크루와 나 모두 새롭게 학습이 필요했지만, react는 레벨 2에서 같이 배워왔기 때문에 최적의 선택이라고 생각했다.

propTypes의 isRequired와 defaultProps의 규칙

prop이 앱 내의 다른 곳의 상태로 있다면 -> defaultProps. 변경될 수 있기 때문에

prop이 정말로 부가적인 것이라면 -> defaultProps. 아니라면 isRequired

defaultProps이 에러도 나지 않고 더 안전해보일 수 있지만, 개발할 때 에러가 발생함으로써 개발자가 쉽게 파악할 수 있는 기회를 놓치게 하기도 함

린터 룰- https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/require-default-props.md