• PR 코드 리뷰를 진행하면서 서로 생각도 나누고 코드에 대해서 가르쳐주고, 질문하는 과정을 잘 보여주고 있는 것이 다른 프로젝트보다 차별 포인트가 된다. 나중에 이력서를 작성할 때 애자일하게 개발하고 코드리뷰하면서 효율적인 의사소통을 한 것에 대해 강조하면 좋을 것 같다.
• 캠핏 사이트처럼 웹과 앱을 다 예쁘게 보여주는 방식을 가능하면 데모데이 이전에 작업해서 시연영상에서 보여주면 좋을 것 같다.
  • 현재는 최대 뷰포트 너비 잡아놓고 백그라운드 색상만 깔아 놓은 상태.
• 회원가입 > 이메일 인증코드 입력 Input에서 숫자 6자리를 입력받는다면, 휴대폰에서 숫자로만 입력되게 하는 input 모드 numeric을 적용하면 좋을 것 같다.
• 회원가입 > 이메일 인증 시 보내는 메일 FORM에 서비스 아이덴티티를 넣으면 퀄리티가 좋아 보일 것이다. HTML로 만들 수 있음.
• 유저의 로그인 여부를 판별하는 protected route를 정의해서, 로그인이나 회원가입 페이지를 제외한 곳에서 전역관리할 수 있게 하기.
  • 유저 정보 조회 API를 요청해서 정보를 받아오면 메인 페이지로, 401에러를 받으면 로그인 페이지로 보내는 등의 작업
  • my info가 계속 다른 곳에서도 사용이 된다면 클라이언트 상태관리가 필요. isLogin을 클라이언트 상태관리에 포함시켜도 됨.
• MSW 추가적인 작업없이 백엔드 API 배포되면 바로 연동작업에 들어가고, 연동이 실패하거나 서버를 내린 후를 고려해서 나중에 MSW 연동도 할것
• UI 좋고 톤앤매너도 맞아서 단점이 크게 보이지 않고 깔끔함. 다만, UX나 디자인이 단순하지 않아서 백엔드 API 연동전까지 프론트 작업이 많아보임. 최대한 공통 컴포넌트화해서 재활용하는 방법 사용할 것. 식단관리나 소셜로그인까지는 못갈 것 같음. API 연동 시 Bottleneck이 무조건 생길텐데 작업이 밀릴거임. 일단 최대한 작업을 해보고 안될 것 같으면 기능축소도 고려해보고, 데모데이 이후라도 못한 페이지 구현을 다 해서 완성해볼 것.
  • 일단 4주차 열심히 화이팅! bottleneck이 생길 때 잘 처리하면 시간을 아낄 수 있으니까 연동과정에서 시간 잘 사용하기.
• 최소 뷰포트는 320px까지 고려하기. 갤럭시 폴드같은 280px까지는 고려하지 않아도 됨.
• 크로스 브라우징 측면에서 어떤 브라우저, 어떤 버전까지 포괄할 것인지 범위를 정하기 (Can I use 사이트)
  • 포괄되지 않는 경우 폴리필 처리되는지 찾아보기
• 리스트에서 특정 항목 삭제 후 처리 로직의 흐름은 상황에 따라 유동적으로 정할 수 있음. 데이터의 변화가 많다면 다시 조회해서 정보를 갱신해야겠지만, 인스타의 내 피드같은 경우 피드 하나 삭제한 후 다시 조회하지 않고 이전 리스트에서 필터링으로 제거해서 보여줘도 괜찮음. 낙관적 업데이트도 있음. API 요청 전에 먼저 화면을 업데이트하고 API 호출하는 방식. 실패하면 다시 화면을 이전으로 돌리기. 인스타그램의 좋아요 버튼이 클릭하면 통신에 관계없이 바로 업데이트가 되고 API 요청을 보내는 낙관적 업데이트 방식. 중요하지 않은 것에 적용.
  • 트레이니 목록 관리 페이지에서 트레이니 삭제는 다시 조회하지 않고 기존 리스트에서 필터링해서 제거하고 보여주는 정도로 해도 상관없을 듯 (삭제 API 요청 후 성공 리스폰스는 확인하기)
• fullcalendar 컴포넌트가 상태가 바뀌어도 리렌더링이 되지 않아서 key방식으로 강제 렌더링을 시키고 있음. 너무 복잡한 로직을 하나하나 고치는 것도 리소스가 들어가니까 key 방식이 나쁜 것은 아님. 최적화의 여지는 있을 것 같음.
• 삼성인터넷 브라우저에서 나눔스퀘어 폰트가 노출되지 않는 문제는 고칠 수 없을 것 같다. 사용자가 시스템에서 직접 선택한 글꼴은 브라우저에 있는 속성을 덮도록 !important 지정이 됨. 그리고 사용자가 선택한 글꼴에 대해 서비스를 하는 웹이 웹폰트를 보여주겠다고 고집을 지키는 게 맞는가? 고민해볼 것. 서비스적인 마인드도 프론트엔드 개발자의 역량.
  • 트러블슈팅에 3시간을 사용했는데, 해결이 안된다고 판단되면 다른 작업으로 돌리는 것이 중요함.
  • 그래도 이 트러블 슈팅 경험 자체는 문제에 대해 집요하게 파고들어서 해결하려는 개발자적인 성향을 보여주기 때문에 내가 이것까지 해봤다라고 면접장에서 스토리텔링으로 사용하면 좋을 듯
• svg 다루는 컴포넌트가 따로 없다면 색상을 바꾸고싶을 때는 어떻게 하면 좋을까? stroke 값을 할당해서 렌더링하는 컴포넌트가 별도로 있으면 svg 하나로 여러색상을 넣어서 사용가능
  • 현재는 다른 색상을 적용한 별도의 svg 파일을 사용 중.
• .vscode 프리티어와 린트 워크스페이스 설정할 것. 다른 개발자가 참여할 때 현재 세팅이 어떤지 반복할 필요없이 프로젝트 내 .vscode 세팅하여 자동화할 것.
  • 현재는 확장 프로그램에서 직접 settings.json을 맞추고 있는데 이렇게 하면 내 컴퓨터에서만 적용되는 것이기 때문에 계속해서 맞춰야 함
  • 확장 프로그램 code spell checker에서 오타를 찾아주거나 카멜케이스가 아니거나 찾아주는 기능 적극 활용할 것. 예외처리할 부분은 settings.json에 같이 설정.
• 테스트 코드는 성공케이스만 작성하지 말고 실패케이스도 고려해볼 것
  • jest보다 vitest를 현업에서 많이 사용하는 추세
  • vitest가 jest 기반이기 때문에 jest를 먼저 사용해보는 것이 순서는 맞는 듯
• 컴포넌트에서 스타일을 먼저 적을지 vs 비즈니스로직을 먼저 적을지는 취향차이
  • 스타일이 많아지면 폴더 내 style 파일을 따로 만들어서 분리하는 방법도 있음
  • 프로젝트 성질에 따라 디자인 패턴은 다양하게 적용. 섞어서 쓰기도 함.
  • 정리를 해주지 않으면 방향성을 못잡으니까 디자인 패턴이 등장한 것.
• routes 파일은 리팩토링해볼 것. 어떤 페이지들이 있는지 한눈에 볼 수 있게 Pages나 views가 있으면 좋을 듯. 비즈니스로직은 따로 분리.
  • 프로젝트 규모가 나눌만큼 크지는 않아서 판단을 잘해볼 것.
  • 보통 이정도 규모에서는 컴포넌트 조립 하는 부분(+조건부렌더링)만 pages에 모아두고 비즈니스 로직은 해당 파일의 service로 빼거나 공통되는 로직은 hook으로 만들어서 분리.
  • gpt에게 관련 디자인패턴으로 작성해달라고 하거나, 다른 프로젝트의 보일러 플레이트 코드 참고
• 애니메이션은 framer-motion을 많이 사용.
  • 페이지 전환을 부드럽게 효과를 주기
  • 모션 자연스러움