- 아직 머지 되지 않은 PR을 기반으로 작업을 이어서 진행해야 하는 경우, 브랜치 전략을 어떻게 하는 게 좋을까요?
- ex) UI에 대한 작업을 올렸는데, 이어서 API 연동에 대한 작업을 해야 하는 경우
- 답변: 상위 이슈, 하위 이슈 등으로 이슈 레이어를 나누고 서브 브랜치 파는 방법. (배포 단위로 상위 이슈.)
- 롤백하기 좋은 스쿼시 머지.
- 롤백하기 좋으니깐. 서브 브랜치를 파서 각자 의존하는 기능을 자유롭게 상위 브랜치에 머지하는 방식.
- dev 브랜치의 사용
- release/날짜 브랜치의 사용
feature 마다 브랜치를 파고 진행하고 merge 를 하는데, 그 브랜치가 애매할 때 (
어떤 브랜치에 넣어야 하는 내용일까 싶을 때, 작업이긴 한데 특정 기능에 묶이는 작업이 아닐 때) dev 브랜치를 사용하기도 함- localhost에 FE 개발서버를 띄우고 작업하는 경우가 많은데, BE 서버에 의존해야 하는 경우(API)에는 현업에서는 보통 어떻게 진행하시나요? 우선 2가지 정도의 선택지가 있을 것이라고 생각했습니다.
- 답변: 프록시 서버.. or 개발 환경 서버
- 개발 환경 서버: 실제 서버랑 거의 같은데, 실제 정보로 개발을 하지 않고 가상의 정보로 개발하는 서버.
- 보통 큰 회사는 3개 이상의 환경을 둠.. (관문 3개. 알파서버, 베타서버, 실제서버)
- Vite Config나.. 프록시 서버 등등..
- SPA의 베타 버전을 또 만드는 방법
- 알파 버전이냐, 베타 버젼이냐에 따라 결과물이 다름.
- 첫 번째: 개발하는 사람 각자가 localhost 에 FE, BE 개발 서버 각각 띄우기
- 문제점: 모든 개발 구성원이 FE+BE 프로젝트를 실행하기 위한 메뉴얼을 숙지해야 합니다.
- 두 번째: 원격에 BE 개발 서버를 띄우고, localhost FE 환경에서 해당 서버에 API 요청.
- 문제점1: HTTP인 localhost가, HTTPS인 dev-BE 서버에 요청하다보니 쿠키 등 인가 처리가 안되는 문제점이 존재했습니다.
- 이 문제점을 해결하기 위해서 프로덕션 코드에 분기 처리 로직이 추가되어야 하는데, 이 부분을 BE 팀원분들이 우려하셨습니다.
- 문제점2: BE 개발 서버에
HTTPS가 걸려있어서, localhost FE를HTTPS로 동작하게 끔 가상의 인증서를 발급하는 과정이 필요했습니다. - 이 경우, 개발 구성원 각자가 컴퓨터에 추가 설정을 해야 하고 FE 입장에서는 실행 스크립트나 Vite 설정 파일을 수정해야 하는 문제가 존재했습니다.
- 현업에서 이미지 업로드 기능은 보통 어떻게 구현하시나요? 생각해 본 방법는 2가지 정도였습니다.
- 답변: 방법은 너무 다양함. 구글 클라우드, 네이버 클라우드 등등 갤러리 형태가 있고.. 리뷰 쓸 때의 형태도 있고.. 에디터도 있고..
- 백엔드와의 합이 중요한 부분.
- cloudinary 같은거 쓰는 경우도 있음. (Serverless)
- 어렵고 고비용의 문제.
- 업로드 뿐만 아니라 다운로드까지 고려해야 함.
- 첫 번째: 이미지와 각종 JSON 데이터를 통째로
multipart/form-data형태로 BE 서버에 전달하는 방법 - 두 번째: FE 단에서 이미지를 S3 에 따로 업로드해 놓고, BE 서버에는 해당 이미지 링크와 각종 JSON 데이터만 전달하는 방법
- 모바일 대응을 고려했을 때 현업에서는 WebView vs PWA 어떤 기술이 더 자주 사용되나요?
- 답변: PWA 잘 안씀.. IOS 때문에.. (17 버전 이상만 사용 가능.)
- 조건부 렌더링이나 조건부 로직이 정상적으로 동작한다는 것은 어떻게 보장하고 테스트하는 것이 좋을까요? 테스트 코드를 도입하기에 적합한 사례일까요?
- 답변: 렌더링 테스트. (조건이라는 Input에 따른 결과 Output을 검증해야 하기 때문.)
- 근데, 렌더링 화면 볼 필요 없이 특정 조건에 맞는 값이 들어오면 JSX에 가는건 알아서 될 것이다 생각하고 안하는 방법도 있음.
- 사용자 입장에서는 오류인데, 개발자 입장에서는 오류가 아닌 테스트 케이스도 있음. (이건 잘못된 커버리지.)
- ex) 방 멤버가 1명일 때 보여줄 화면과, 10명일 때 보여줄 화면이 다른 경우
- ex) 본인이 방장인지, 참여자인지에 따라 보여줄 화면이 다른 경우
- 플로우 같은 거 2개 정도.
- 사용자 대상 말고, 개발자 대상으로 어떻게 코드를 보여줄 것인가.. 등
기획서 피드백
전반적으로 좋음. (사용자 시나리오나 플로우 등등)
그러나, 개발자로서 취업을 위해서 도식화는 더 많았으면 좋겠음.
지금은 비개발자도 보면 이해할 수 있는 플로우만 가득함.
스토리 보드와 시나리오는 대박인데, 이게 어떻게 코드로 구현되었는지 까지 보여주면 좋을 듯.
(왜 이렇게 구현했고, 어떻게 했는지.. 등)
(ex) 배포 파이프라인, 컴포넌트 구조, 디렉토리 구조, 협업 파이프라인 등등..)
노션에 너무 강결합 되어있음. 깃헙만 봐도 해결되도록 하면 좋을듯.
에러 트래킹에 Sentry 도입해보면 좋을듯.