기초 프로젝트 회고

[shyjnnn]

기초 프로젝트에 대한 회고를 하고(#29), 댓글을 남겨주세요🙏

• 기한: 24.09.03 (화) 1교시까지

[mjpark-k]

• Keep (유지할 점)
  • 정해진 회의 시간에 진행 상황 및 논의해야 할 사항에 대해 원활하게 의견을 나눴다.
  • 개인 작업 중간에 막히는 부분이나 수정 사항, 논의해야 할 주제가 생기면 부담 없이 얘기를 하여 소통했다.
  • 이번 주 협업을 하면서 어려운 작업을 마주친 적이 많은데, 혼자였다면 힘들고, 오래 걸렸을 것 같은데 팀원들의 도움을 통해 해결이 돼서 편안했습니다.
  • 프로젝트에서는 ‘기업 비교’ 페이지를 맡아서 작업했으며, 최대한 세세한 부분을 놓치지 않기 위해 꼼꼼히 구상을 하며 작업을 진행했습니다.
• Problem (문제점)
  • 서로 다른 명명 규칙이나 코딩 스타일을 서로 조율하는 부분에서 조금 오래 걸렸지만, 대중적으로 통용되는 방법을 최대한 사용하는 쪽으로 해결하여 잘못된 습관이 있는 팀원은 고치게 되는 계기가 됐다.
  • 규칙을 미리 정하고 갔음에도, 클래스 네이밍같은 곳에서 겹치는 상황이 발생하기도 하여, 한 명이 수정하게 됐습니다.
  • 제가 맡은 ‘기업 비교’ 페이지에서 세세한 기능과 배열 메서드 활용 부분에서 진행이 더딘 문제가 있었는데, 처음엔 구글링 등 검색으로 정보를 찾고, 그 뒤로도 어렵다 느껴지면 팀원들과 소통하여 도움을 청하고, 팀원들과도 어렵다 느껴지는 부분에서는 강사님과 멘토님에게 조언을 구하여 해결했습니다.
• Try (시도할 점)
  • PR의 비중이 조금 더 있어야 될 것 같고, 미리 코드를 세세하게 알 필요를 느껴서, 그렇게 해보고 싶습니다.
  • merge 쪽에서는 팀원들과 자세한 소통을 통해 최대한 conflict가 발생하지 않는 쪽으로 하고 싶다.

[WooHyunTak]

1주차

1. 주제선정, 팀 페이지 작성

• 각 파트의 컨벤션 등과 같은 팀내부의 규칙 정하기
• 요구사항 파악
• 팀원 R&R 정하기

개발 직무의 특별 성보다는 어느 직무에서건 사전준비가 중요하다고 생각한다.
사전준비의 시간을 투자하는 것과 비례하여 진행하면서 발생할 문제들을 미리 대비하고 준비할 수 있다 라고 생각한다.
1주 차는 나 개인의 작업보다는 팀원들과의 소통의 시간이 더 많이 가지고 가는 것으로 결정했다.
모든 분야에서 협업의 중요하지만, 개발분야는 특히 더 협업의 중요성을 강조한다. 각각의 개인마다 생각하는 관점이 다르기에 그러하다
예를 들어 함수/변수의 이름을 정하는 것, 그리고 협업 툴의 커밋이라고 하는 내용도 그러하다 이러한 전반적인 내용을 컨벤션이라고 정의하여 개인의 R&R을 분배하고 작업을 진행할 때 따로 회의나 소통하지 않아도 기본적인 것을 컨벤션 규칙의 맞춰서 정의한다면 추후 작업물을 병합할 때 이점을 많이 가지고 갈 수 있다.
개인적으로 유지되어야 할 점은 개발자 도구를 적극적으로 활용하는 방법이 좋은 거 같다. 프런트와 백을 동시에 개발을 진행할 때 코드상의 에러 핸들링을 잘 진행하였다면 콘솔/네트워크 탭에 기록이 자세히 나와 버그 수정의 이점을 가지고 갈 수 있다.
코드를 작성하는 측면에서는 ＇추상화 ＇ 관점에서 중복되는 코드를 줄이는 방식으로 작업을 진행하는 것이 좋을 거 같다.
계속해서 고민하고 전목해야 하는 점은 코드를 작성하기 전에 로직을 생각하고 코드의 흐름을 조금 더 생각을 하고 작업에 들어가는 것이 좋을 거 같다. 간단하게 생각을 한다면 진행 중 다시 롤백하는 경우가 다소 있었다.
조금 더 노트가 되었든 사용자의 흐름과 코드의 흐름을 먼저 파악하고 시작하는 버릇이 필요해 보인다.

2주차
1.view my start up - 기업 비교 파트

데이터베이스르 다루는 경우가 많은 파트였다고 생각을 한다.
prisma와 같은 ORM을 사용하는 것이 익숙하지 않은 것이 조금은 문제가 있는 거 같다.
지금 생각해 보면 조금 더 편하게 데이터를 핸들링할 수 있었겠다 하는 부분이 있다.
가장 먼저 고민하게 했던 부분은 테이블의 전체 데이터의 정렬기준의 맞춰 랭킹을 하는 것이었다.
프로젝트에서 오프셋 방식으로 데이터를 잘라서 조회 후 전달을 받는다.
여기서 생각을 한 것은

1. 프론트에서 데이터의 랭킹을 한다면 올바른 순위가 나올 것인가.
2. 만약 전체의 순위가 필요하다면 데이터의 양이 많아지면 속도의 측면에서 이점이 없다.

위 두 가지 문제를 나는 SQL문을 직접 쿼리 하는 방식으로 진행을 했다.
이 부분에서 많은 시간을 투자하게 된 거 같다. 하지만 팀원분들께서는 프론트에서 오프셋을 활용해서 랭킹을 프론트에서 정의를 하였다.

이 부분에서 팀원분들께서 생각이 정말 유연하다고 생각을 했다.
여러 가지 방면에서 고민을 하는 것은 좋은 습관이라고 생각이 들지만 한 가지 방법이 생각이 난다면 다른 해결방법의 경우의 수를 생각하지 않는 것은 좋지 않은 거 같다.
조금 더 간단하고 보기 편한 코드를 만드는 것도 중요하다고 생각을 했다.

[ajantang]

keep

• 적극적인 소통/먼저 다가가는 소통
• 자세한 코드 설명/리뷰
• 노션(또는 문서화) 작업 : 회의록 / 일정 관리 / 안건 정리 / 자료 공유 / 규칙 정리 등
• retrospective meeting

problem

• BE 테스트 과정에서 발생하는 문제 해결이 어려움(디버깅) : 실제 서버에 올라갔을 때와 로컬에서의 결과가 달라 로직의 문제점을 확인하는 데 시간이 오래 걸림
• 로컬 말고 실제 서버로 올렸을 때 테스트 필요
• 프로젝트 시작 템플릿에 라이브러리나 폴더 구조 등을 모두 추가하지 않은 상태에서 시작해서 규칙으로 정한 내용과 다른 식으로 사용한 팀원들이 생김
• 소통 시간에 비해 소통 결과가 양/질 적인 면에서 부족함
• 페이지 단위로 나눈 업무
• 소통하는 과정에서 제 의도와는 다르게 상대가 이해하는 경우
• 프로젝트 후반에 노션 관리가 부족함
• 팀 총괄 + 개인 업무를 하는데 조금은 벅찬 느낌(회사에서의 책임감+@)

try

• BE 개발 과정에서 테스트용 API 또는 테스트 코드 사용
• 세부 컴포넌트 단위로 업무를 나눠 컴포넌트 사용시 자연스럽게 담당자와 소통의 기회를 늘림
• 프로젝트 시작 시 레포 공유 전 파일 구조/폴더 구조를 미리 만들고 레포 공유
• 소통하는 동안 최대한 상세한 설명을 이야기하고, 중요한 부분은 상대의 이해 내용을 확인
• PR / git / 타 스케쥴 관리 프로그램 사용 시도
• 팀장을 하지 않음

[dieuaimer]

Keep (유지할 점)

1. React Context의 효율적인 활용: React Context를 통해 컴포넌트 간의 데이터 전달 문제를 해결한 점은 긍정적이었다. 특히, useContext 훅을 사용해 코드가 단순화되고, props drilling 문제를 극복할 수 있었다.
2. Context의 구조와 사용법에 대한 깊이 있는 이해: Context의 기본 구조와 사용법을 깊이 이해하고, 이를 실제 프로젝트에 성공적으로 적용한 경험은 앞으로도 계속 유지할 가치가 있다.
3. 에러 디버깅과 해결 과정: InvestmentProvider를 활용한 전역 상태 관리에서 발생한 에러를 신속하게 디버깅하고 문제를 해결한 경험은 매우 유익했다. 이는 앞으로 복잡한 상태 관리 문제를 해결하는 데 큰 도움이 될 것이다.

Problem (문제점)

1. 무한 리렌더링 문제: useEffect 훅의 의존성 배열에 특정 함수를 추가하면서 무한 리렌더링 문제가 발생했다. 이는 의존성 관리의 중요성을 다시 한번 상기시켜주었으며, 의존성 배열을 설정할 때 더 신중해야 할 필요가 있었다.
2. 즉각적인 화면 반영 어려움: 초기에는 투자 내용이 변경될 때 화면에 즉각적으로 반영되지 않는 문제를 window.location.reload()와 같은 임시 방편으로 해결했지만, 이는 최종 솔루션이 아니었다. Netlify에 배포 후, SPA(Single Page Application)에서 발생하는 Page Not Found 오류를 겪으며, 새로고침 방식이 적절하지 않음을 깨달았다.

Try (시도할 점)

1. 의존성 배열 관리 개선: 앞으로는 useEffect 훅의 의존성 배열을 더 철저히 관리하고, 불필요한 리렌더링을 방지하기 위한 방법들을 연구할 것이다. 이를 통해 더 안정적이고 성능이 향상된 애플리케이션을 개발할 수 있을 것이다.
2. 상태 기반 업데이트 방식 도입: 최종적으로 useState를 사용해 데이터의 상태가 변할 때마다 version을 업데이트하는 방식으로 데이터를 관리했다. 이는 화면에 즉각적으로 변화를 반영하고, Netlify 배포 후에도 안정적인 동작을 보장했다. 앞으로는 이러한 상태 기반 접근 방식을 더욱 효과적으로 활용할 방안을 모색할 것이다.

[Minsugar98]

Keep (유지할 점)

- 공통 컴포넌트 분배, 브랜치 전략을 사용
- 정해진 회의 시간에 진행 상황 및 논의해야 할 사항에 대해 원활하게 의견을 나눔
- 팀원 소통

Problem (문제점)

- 컴포넌트 Props 공유
- 규칙을 미리 정해도, 아직 팀프로젝트에 익숙하지 않아서 제대로 수행되지 않음

Try (시도할 점)

- 페이지별로 이동할 때 공통으로 상용하는 Props 내용을 미리 정리해서 프로젝트 시작해 보기
- 팀원들과의 코드 리뷰 (작성했던 방식, 이유 등등 설명)

[kangbeomjoon]

• KPT
  • 1. Keep (계속할 것)
    • 포기는 금물: 지난 2개월의 부트캠프 기간 동안 수업 진도와 과제 제출하는 것에 생각 없이 맹목적으로 흘러가다보니 정작 혼자서는 스스로 코딩도 못하고 항상 Gpt를 이용해서 코드 짜는 것을 부탁했습니다. 이번 팀 프로젝트를 계기로 창피하고 내 실력 바닥인 거 들켜도 상관없으니 실례 되더라도 팀원에게 무조건 도움을 청하자는 생각으로 많은 도움을 청했고 다행히 너무나 친절한 피드백을 받을 수 있었기에 끝까지 포기하지 않을 수 있었습니다.
    • 배움의 자세: 모르는 건 부끄러운게 아니기 때문에 도움 받을 팀원이 있으면 물어보고 앞으로도 학생의 자세로 열심히 배우고 저도 그 좋은 영향력을 이어받아서 나중에 기본이 잘 갖춰졌을 때 누군가에게 선한 영향력을 공유할 수 있다고 생각합니다.
  • 2. Problem (문제점)
    • 이론의 적용 부재: 백엔드 개발의 기초 강의를 수강했음에도 팀 프로젝트에 어떻게 적용할 지를 몰라서 과제 제출일이 다가옴의 이유로 이 부분을 팀원 분께서 대신 해주었습니다.
    • 더 적극적인 자세: 팀원들끼리의 오고 가는 대화속에 내가 이해되지 않는 부분이 너무 많아 ‘이건 그냥 넘어가자’는 생각으로 안일한 대처를 한 시간이 많았습니다. 이 부분은 수정하여 좀 더 집요하게 파고 들어야 할 것 같습니다.
  • 3. Try (시도할 것)
    • 더 나은 설계 방법 학습: 다음 과제에서는 시작하기 전에 요구사항을 철저히 분석하고, 설계에 충분한 시간을 투자할 계획입니다. 배운 이론 내용을 직접 하나 하나 코드로 다 짜보고 실습으로 실행해보고 나의 것으로 체화 시키는데 시간을 많이 써 다음 프로젝트에서는 1인분 이상의 성과를 내려고 합니다.
    • 미리 준비하는 자세: 이번 초급 프로젝트가 끝나면 또 다시 이제 다음 단계로 넘어가기 위해 학습 진도를 나갈텐데 이론을 배우기 전에 그 이론 강의 영상을 한 번이라도 먼저 보고 진도를 나간 날에 조금이라도 스스로 코드를 짜는 수준으로 만들어야 겠다고 느꼈습니다.

[juyeongeun]

• 유지할 점 (Keep)
  • 실시간 소통으로 코어타임 외에 발생하는 문제나 수정사항을 실시간 소통 도구를 통해 팀원들과 빠르게 해결할 수 있었다.
  • 코드 리뷰와 피드백을 통해 팀원 간의 코드 리뷰를 통해 다양한 개발 방식을 학습할 수 있었다.
• 문제점 (Problem)
  • 팀원 간의 다양한 개발 방식을 존중하면서도, 코드 스타일이 일관되지 않은 경우가 발생해 코드 유지보수의 어려움이 있었다.
  • 전체적인 스케줄 관리가 미흡하다 보니, 프로젝트 완성은 했지만 일부 작업의 품질이 희생되는 상황이 발생할 뻔 했다.
• 시도할 점 (Try)
  • 스케줄 관리가 품질에 미치는 영향을 최소화하기 위해, 중간 점검 및 품질 보증 프로세스를 강화할 필요가 있다고 생각한다.
  • 코드 스타일의 일관성을 유지하기 위해, 팀 내에서 코딩 가이드를 마련하고 이를 지킬 수 있도록 최대한 노력한다.
  • 팀원들의 강점과 전문성을 분석하여 이를 기반으로 R&R을 분배한다면 작업이 더욱 효과적으로 완료될 수 있, 팀원들의 능력을 최대한 발휘할 수 있다고 생각한다.

[songyoungsub]

keep

1, 지속적인 소통을 통해 서로를 보완
2, 개발 규칙과 팀원 규칙
3, 노션을 이용한 안건 및 개발 내용 정리

problem

1, 규칙이나 파일 구조를 정해도 예상 외의 파일들이 있어 잘 지켜지지 않음
2, 로컬에서 테스트한 것과 서버에 올려 테스트한 것의 결과가 다르게 나옴
3, 에러 수정을 위한 시간 할당으로 시간 부족

try

1, 정한 규칙에 없는 공통으로 해당하는 내용의 안건이 있으면 혼자 해결하지 않고 팀원과 소통을 통해 결정한다.
2, 테스트 코드를 공부하여 작성해 오류가 없는지 어디서 오류가 발생하는지 확인한다.

[mozzi34]

Keep (유지할 점)

1. 팀원간의 소통
2. 공통 컴퍼넌트와 파일 구조

Problem (문제점)

1. useEffect 부분에서 네트워크를 계속 요청하는 문제 발생
2. 일괄되지 않은 코드 스타일

Try (시도할 점)

1. useEffect의 필요 유무를 다시 한번 의심해 보면서 적절하게 사용할 수 있게끔 확인해 보기
2. 코드 품질과 가독성을 향상시키기 위해 팀 내에서 명확한 규칙을 세워 보기

[S2OHEE]

📘 Keep (유지할 점)

• 명확한 일정과 정기적인 리뷰의 중요성: 매주 월/수/금 오후 5시에 코드 리뷰를 정기적으로 진행하였습니다. 정기적인 코드 리뷰와 명확한 일정 설정이 팀원들 간의 협업을 보다 원활하게 만들어 이를 통해 코드 리뷰 시간을 명확히 정해두고, 각자의 작업 진도를 체크하여 작업을 기한 내에 완료함으로써 효율적으로 진행할 수 있었습니다. 또한, merge 시 충돌이 발생할 가능성을 사전에 공유하고 해결함으로써 문제를 원활히 해결할 수 있었습니다.

• 실시간 소통과 즉각적인 피드백: 매일 디스코드를 통해 팀원들과 실시간으로 소통하며 문제를 즉시 해결할 수 있었습니다. 또한 수정이 필요한 부분이나 추가적인 사항은 사진 캡쳐와 함께 디스코드에 공유하여 빠르게 반영할 수 있었습니다. 팀원간의 즉각적인 피드백을 주고받는 것이 프로젝트 진행에 긍정적인 영향을 미쳤습니다.

본인이 기여한 부분( BE )

• 기업 상세조회 API 구현 :
  기업의 ID를 매개변수로 받는 기업 상세조회 API를 담당하였고, 백엔드 API 기능 구현을 완료하여 PR을 제출했습니다. 중간에 발생한 문제나 피드백이 필요한 부분은 디스코드나 소회의실에서 신속하게 의견을 주고받아 원활히 진행되었습니다.

• 투자 현황 페이지 구현 및 API 연동 :
  프론트엔드에서 기업 전체 리스트 조회 API를 호출하여 데이터를 받아오고, 해당 데이터가 제대로 표시되는지를 확인했습니다.

우수한 PR 및 코드 리뷰

• PR 링크: [김소희] 투자현황 페이지 구현 및 API 연동 ViewMyStartup/view-my-startup#42
• 잘된 점: PR의 코드 리뷰는 기능 구현의 명확성, 코드의 가독성 등을 신경 써서 작성했습니다.
• 가독성 개선: 변수명, 함수명 등을 명확하게 작성하여 코드의 가독성을 높였습니다. 각 함수 및 모듈의 역할을 문서화하여 코드 리뷰어가 이해하기 쉽게 작성했습니다

📘 Problem (문제점)

• 프론트엔드와의 통합 테스트 시 발생한 호환성 문제: API를 프론트엔드와 통합하여 테스트하는 과정에서 데이터 표시 문제를 경험했습니다. API가 반환하는 데이터 형식과 프론트엔드에서 기대하는 데이터 형식 간의 불일치가 주요 원인이었습니다. 이로 인해 프론트엔드에서 데이터가 제대로 렌더링되지 않거나 일부 정보가 누락되는 문제가 발생했습니다.

• 문제 및 어려웠던 부분: API 통합 테스트 시 기존 프론트엔드 코드와의 호환성 문제로 수정이 발생했습니다. 특히, API 응답 구조와 프론트엔드에서 데이터를 처리하는 방식 간의 차이로 인해 코드 수정과 데이터 변환 작업이 잦았습니다.

문제 해결을 위해 시도한 방법:

• 정기적인 소통 강화: 팀원들과의 정기적인 소통을 통해 발생할 수 있는 문제를 사전에 파악하고 조정했습니다.
• 코드 리뷰 및 사전 협의: PR을 통해 코드 리뷰를 받으며 충돌 가능성을 미리 검토하고, 필요한 수정 사항을 팀과 협의하였습니다.
• 통합 테스트 수행: 수정된 API와 프론트엔드 간의 통합 테스트를 반복적으로 수행하여 데이터 호환성 문제를 해결했습니다

📘 Try (시도할 점)

• 팀원 간의 소통 강화: 첫 팀 프로젝트 마무리 단계에서도 팀원 간의 소통을 더욱 활발하여 문제 없이 프로젝트를 잘 마무리할 수 있었습니다.

• 문제 발생 시 신속 대응: 다음 팀 프로젝트에도 팀원들과의 긴밀한 소통을 통해 발생할 수 있는 문제를 신속하게 파악하고 대응하여 프로젝트가 원활히 진행되도록 노력하겠습니다

[charlieko123]

• Keep

  • 처음에 작업을 분배하는 과정에서 페이지 단위로 관련 컴포넌트, 레이아웃, 관련 백엔드 API까지 작업을 분배할지 고민하다가 결국 하위 컴포넌트, 상위 컴포넌트, 페이지, 백엔드 API 등 전체 작업을 사다리타기로 랜덤하게 부여하였다.
  • 이렇게 단계별로 랜덤하게 작업을 나누다 보니, 다음 작업을 진행할 때 다른 팀원이 제작한 컴포넌트를 사용하게 되어 자연스럽게 서로의 코드를 자주 보게 되고, 본인이 발견하지 못한 문제점이나 개선할 점들을 발견해 논의하고 수정하는 등의 커뮤니케이션이 자주 발생하여 협업하는 느낌이 들어 좋았다. 또한, 다른 파일에서 공통적으로 사용되는 컴포넌트를 수정할 때는 가능한 다른 컴포넌트에 변경이 일어나지 않는 선에서 prop이나 코드를 추가할 수 있도록 노력한 것 같다.

• Problem

  • 백엔드 파트에서는 기업 비교하기 API 부분을 맡았는데, 작업 후 코드 리뷰를 받아보니 요구사항을 제대로 충족하지 못한 부분이 많아 팀원분들의 도움을 많이 받았다. 전체적으로 부족한 부분이 많았지만, 특히 백엔드 쪽의 이해가 좀 부족한 것 같다.
  • 개인적으로 기업 카드 컴포넌트에 드래그 앤 드롭 효과를 넣어 삭제할 수 있게 만들면 재미있을 것 같아서 시도해봤는데, 여러 에러가 발생하고 해결한 것 같았지만, 애초에 코드 자체가 잘못되었던 건지 드래그 앤 드롭 기능이 원하는 대로 동작하지 않아서 결국 브랜치를 초기화했던 경험이 아쉬웠다.

• Try

  • 프로젝트를 진행하며 팀원분들의 개발뿐만 아니라 다양한 부분에서의 뛰어난 능력들을 보면서 감탄하며, 노력을 많이 해야겠다는 생각을 하게 되었다. 스스로 조금 더 적극적으로 활동하며 배울 수 있으면 좋겠다.

[mini-1018]

Keep(유지할 점)

• 공통 컴포넌트를 제작하여 재사용성을 높인 점
• 규칙적으로 팀미팅과 소통하는 시간을 갖은 점
• 일부 코드 컨벤션과 같은 팀 규칙을 정한 점

Problem(문제점)

• 1주차에 코드 리뷰를 비중있게 하지않아 2주차에 팀원들 코드 공유 및 문제해결 시 시간이 다소 소요된 점
• 코드 컨벤션을 구체적으로 세분화하지 않아 페이지별 머지 후 클래스 네임이 중복된 점
• 프론트엔드 api 코드를 통합하지 못한 점

Try(시도할 점)

• 코드 컨벤션 네이밍 규칙과 함수선언 방식을 자세하게 세분화할수록 좋다는 것을 느꼈고 다음 프로젝트에서는 더 나은 컨벤션을 적용하고 싶은 점
• 예를들어 온클릭 이벤트 처리마저도 각자의 스타일이 다 다르기 때문에 널리 사용되는 디자인 패턴을 일부 적용해 재사용성, 유지보수, 통일성을 높여보고 싶은 점
• 상태를 꼭 필요한 곳에만 유지할 수 있도록 Memoization, 리액트훅을 앞으로는 적극 활용해보고 싶은 점
• 최대한 재사용성과 가독성 높은 간결한 컴포넌트를 만들고 유지하고 싶은 점
• 깃에 자주 커밋하고 명확한 브랜치 명과 그 브랜치명에 맞는 기능만 머지하도록 습관을 갖고 싶은 점

[wxy0415]

KPT회고

Keep (유지할 점)

• 소통을 열심히 하며 팀원들과 의견을 공유한점
• 여러 아이디어를 시도해보고 적합한 기능을 찾기 위해 시도함 (useDebounce)
• 우선순위를 파악하여 업무의 순서를 적절히 판단한점

Problem (문제점)

• GitHub 사용이 미숙해서 업무에 지장이 있음
• 팀원들 코드리뷰 해줄 실력이 안됨
• 페이지의 대략적인 기능을 파악하지 않고 무작정 작업한점
• 팀 프로젝트 경험 부재로 여러 실수가 있었음
  • global css 문서를 임의로 수정해서 문제가 생김
  • 파일 구조를 임의로 수정해서 병합할때 문제가 생김

Try (시도할 점)

• 클린 코드를 위해 여러 서적 찾아보기
• 더 적극적인 소통을 통해 다양한 관점에서 문제점 해결하기
• 스케줄 관리를 더 철저하게 하기

[choco-lic]

Keep (유지할 점)

• 막히는 부분을 팀원들과 소통하여 해결할 수 있었습니다.
• 소통이 중요하구나 느꼈고 소통으로 인해 프로젝트를 더 빨리 마칠 수 있었던 것 같습니다.
• 저는 기업 전체 리스트, 비교 현황, 투자 현황 페이지를 맡았고 시안과 똑같이 구현하려고 노력했습니다.

Problem (문제점)

• 리액트를 사용함에 있어 어려웠습니다.
• 팀원들에게 공유하고 코드를 다운 받아 그 파일을 수정했습니다.
• 2줄이상 길어지면 말줄임표로 표시해야하는 부분이 있었는데 글자 수 제한하는 방법을 택했다가 반응형에선 적용되지 않아서 고민했습니다.
• 팀원분들과 함께 고민한 결과 높이를 제한하는 방법으로 해결할 수 있었습니다.

Try (시도할 점)

• 좀 더 공부해서 부족한 부분을 채우고 싶습니다.

[claudia99503]

Keep

• 공통 컴포넌트를 함께 개발한 점
• 팀원분들이 공통 컴포넌트에 대한 2차 수정사항을 실시간으로 공유해주신 점
• 최소 단위 컴포넌트 개발자와 중간 단위 컴포넌트 개발자를 분리하여, 최소 단위 컴포넌트에서 미흡했던 부분을 중간 단위 컴포넌트 개발자가 보완해준 점
• 월/수/금으로 PR을 발행하는 날을 정해, 구현된 캡처본을 첨부해 가독성을 높인 점
• 사전에 협의된 코드 컨벤션을 잘 준수하여, 문제가 발생하더라도 쉽게 해결할 수 있었던 점

Problem

• 프론트엔드 페이지에서 선언된 변수명 구조와 백엔드 구현에서 각 팀원이 프론트엔드 페이지를 독립적으로 작업하지 않고 공통으로 개발했기 때문에, 변수명이 서로 달라서 혼란이 발생함

Try

• 재사용성을 고려하여 코드를 리팩토링해보기

[J-Jun5]

프로젝트 회고

프로젝트 전반에 대하여

대학/회사 생활을 통해 협업에 대하여 익숙해졌다고 생각했지만,
새로운 환경과 직무에서 또다른 협업을 진행하면서 커뮤니케이션에 대한 중요성을 다시 한번 느끼게된 계기가 되었던 것 같다.

중요한 것은 아무리 작은 정보라도 그때그때 해당 정보를 전달한다면 그것이 프로젝트 활동에 매우 도움이 된다는 것이다.
예를들어, 진행하고 있는 작업이 금방 끝날 것 같아도 작업이 끝나고 하는 것이 아니라,
바로 해당 작업이 곧 끝날 것이라는 것을 전달한다거나 혹은 어떠한 선택지 중에서 고민을하고 있는 상황에서
결정이 정해지기 전에 특정 선택지 중에 결정을 고민하고 있고 아마 어떤 선택지를 선택할 것 같다 라고 전달한다거나.

또, 만족스러웠던 점은 지키기 어려운 규칙을 너무 많이 정할 경우 프로젝트 진행이 되려 힘든 경우가 많은데,
이번 팀 활동은 규칙과 일정 모두 최소한으로 정하고 진행하면서 빠르게 프로젝트를 마무리할 수 있었고
각자가 가진 다양한 아이디어들을 프로젝트에 녹일 수 있었던 것 같다.

이 외에도 일정 같은 경우에는 100%의 리소스를 투입했을 때 완료할 수 있는 일정으로 정하는 것이 아니라
50 ~ 75% (개인적인 기준) 리소스를 투입했을 때 완료할 수 있는 일정으로 정하는 것이 중요한데
이러한 부분도 이번 프로젝트에서 잘 반영이된 것 같다.

잘한 점

1. 최대한 협업을 염두하고 페이지에서 상태를 관리할 수 있도록 작은 단위 컴포넌트 개발부터 신경써서 작업했다.
   • 컴포넌트의 props들을 예상해서 미리 정의하고 코딩했다.
2. 백엔드에서 기업의 VMS 모의 투자 금액의 경우, 데이터를 시딩할때 따로 데이터를 넣지 않았다.
   • 모의 투자 금액은 각 투자자의 금액을 합산한 금액이기 때문에 이 점을 반영해야 된다고 생각하여,
     시딩 스크립트 로직을 기업 데이터 시딩 > 투자자 데이터 시딩 > 기업별 투자자의 InvestAmount를 SUM
     및 VirtualInvestment를 업데이트 해주는 방식으로 구현했다.
3. 최상단의 PageNav를 구현할때, 미리 페이지 경로들을 Link로 등록해두고 useLocation 훅을 활용하여,
   추후 라우터 등록과 페이지가 구현될 경우 각 페이지로 이동하고, 이동된 후에
   해당 Nav메뉴에 Bold 스타일이 적용되도록 페이지 작업 단계 사전에 구현했다.
4. 작은 단위 컴포넌트 개발 단계에서 각자 App.js를 통해 컴포넌트 테스트를 진행했는데,
   이후 페이지 작업 단계에서 라우팅 설정으로 인해 해당 테스트 코드들을 사용할 수 없는 상황이였지만,
   /test 페이지를 별도로 생성하고 해당 페이지에 코드를 옮겨서 자유롭게 컴포넌트들을 계속 테스트할 수 있도록 하였다.

아쉬운 점

1. 기업 정보를 보여주는 표가 페이지별로 조금씩 컬럼이 다른데,
   해당 구현을 1개의 CompanyDataPerRow컴포넌트에서 각 타입별로 렌더링해주는 함수를 여러개 정의하고
   type이라는 props를 두어서 다른 작업자들이 컴포넌트를 사용할때 type을 정의해주면
   페이지에 맞는 컴포넌트를 렌더링해줄 수 있도록 구현했다.
   • 해당 컴포넌트의 코드가 너무 길어지는 결과를 낳았고 오히려 코드 가독성을 떨어뜨려 다른 팀원들의 작업에 영향을 주었던 것 같다.
2. 기업 정보를 보여주는 표에서, 위에 설명한 CompanyDataPerRow컴포넌트와 헤더 부분을 그려주는 HeaderColumn 컴포넌트를 생성하고, 다시 이 2개의 컴포넌트를 합쳐서 전체 표를 렌더링해주는 DataRowSetRender컴포넌트를 구현했다.
   • 실제 데이터는 최종적으로 CompanyDataPerRow 컴포넌트에서 사용하고 있어서
     페이지 구현단계에서 해당 컴포넌트를 사용할 때, 페이지 > DataRowSetRender > CompanyDataPerRow를
     왔다갔다 해야하는 문제가 있었다.
   • 오히려 이러한 구조가 나 뿐만 아니라 다른 팀원들의 원활한 페이지 작업을 방해했다고 생각한다.

기타 느낀 점

1. 이모지를 활용한 커밋 컨벤션에 대한 만족도가 높았다.
2. 이번 프로젝트 활동을 통해 스스로도 리액트와 프리즈마, PostSQL 사용에 대해 복습하는 시간을 가졌고,
   한층 더 풀스택 개발에 대한 이해도가 높아졌다.
3. 컴포넌트 개발 시 더욱 유연하게 코딩을 해보고 싶은 마음이 생겼다.
   • 공통으로 여러 곳에 재사용되는 컴포넌트는 크기를 설정하지 않고 작업한다면,
     다른 작업자들이 Div를 통해서 크기를 설정하여 자유롭게 사용할 수 있지 않을까? 라는 생각을 하였다.
4. 이번 프로젝트에서는 최대한 팀원의 코딩 방식을 존중하고,
   수정이 필요할 경우에도 해당 방식을 최대한 유지하면서 수정을 진행했는데
   전체적으로 일관된 코드를 작성하는게 좋은 방향일지, 혹은 팀원들의 각자의 코딩 방식을 존중하는 방식이 좋은 방향일지 궁금하다.

프로젝트 활동

1. 피그마 분석 및 단계별 컴포넌트 개발 제안
   • 컴포넌트 기능/크기별로 3단계로 분류 및 공유
   • 원활한 초기 프론트 작업에 기여
2. Netlify, Render 초기 세팅 및 배포 관리
   • 웹 사이트, API 서버, DB 서버
3. 데이터 모델링 및 시딩 스크립트 개선 및 DB 관리
   • 프로젝트 데이터 관리 개선에 기여
4. 비교 현황 페이지, 투자 추가/삭제 API 구현
5. 기업 정보 표 로딩 스피너 및 애니메이션 구현
   • 공통 컴포넌트에 적용하여 모든 페이지에 즉시 적용
6. 최종 발표 자료 정리 및 프로젝트 마무리 회고 제안

문제/이슈

1. 백엔드 서버에서 이미지 정적 제공이 되지 않던 이슈
   • 절대 경로/상대 경로 등 몇차례의 경로와 코드 수정을 진행하였으나 해결이 되지 않음
   • 정확하게 파악되지는 않았지만, Render를 통해 백엔드에 빌드했기 때문에
     /images 경로가 아닌 배포된 Render URL 링크를 사용해야하는 것으로 추정
   • 위 내용대로 DB에 저장된 이미지 링크들을 Render URL 로 변경하여 해결
2. 프로젝트 마무리 단계에서, 기업 이미지 로딩이 오래 걸렸던 이슈
   • 배포 서버 위치도 문제가 어느정도 있었지만, 백엔드 서버에 빌드된 이미지를
     프론트에서 다운로드 해오는 과정에서도 지연이 발생한다고 생각되어, 프론트에 이미지를 함께 빌드하는 방식으로 해결 및 개선
   • 태블릿 이하 사이즈에서, 기업 상세 페이지 하단의 투자 코멘트 표에 Y축 스크롤이 생기는 문제와
     마지막 코멘트 Row에서 투자 수정/삭제 모달이 잘리는 이슈
   • 수정/삭제 모달이 코멘트 표를 그려주는 컴포넌트에서 관리되어 발생한 문제로,
     수정/삭제 모달을 컴포넌트로 분리하고, 컴포넌트가 아닌 페이지 위에서 렌더링 되도록 로직을 개선
   • 케밥 이미지를 클릭할 경우 해당 위치를 수정/삭제 모달에 전달하여, 해당 위치에 열리도록 구현
3. Git 전략에 대한 이슈와 고민
   • 초기 Git 전략을 스프린트 미션과 동일하게 원본 레포 > 포크 레포 > 포크 레포 브랜치에서
     각자 작업을 하고 원본 레포로 PR하는 방식을 사용
   • 해당 방식대로 사용할 경우, 원본 레포에 작업 커밋 기록이 남지 않는 이슈 확인
   • 어떻게 하면 각자 작업 브랜치를 분리하고, 커밋 기록도 보관할 수 있을지 자체적으로 고민을 많이 진행함
   • 고민한 시간에 비해 생각보다 간단한 이슈였으며, 원본 레포에서만 브랜치를 생성하여 작업하는
     GitHun Flow 전략을 제안하고 멘토링 시간을 통해 멘토님 의견까지 확인한 뒤 해당 방식으로 변경

[yoorli]

• Keep
  • BE
    • 백엔드 작업 진행 - 프로젝트 특성 상 관계형 데이터베이스가 더 잘맞다고 생각 → PostgreSQL 사용
    • 동일한 백엔드 작업을 진행 - 배우는 단계여서 팀원들이 모두 같은 작업을 진행해도 괜찮다고 생각, 모든 팀원이 동일한 부분을 작업 후 비교 → 같은 부분을 작업해도 코드 내용은 달라서 다양한 유형을 비교할 수 있었음
    • 다같은 부분을 코딩하니 , 문제가 생겼을 때 어느 부분인지 모두가 정확히 인지하고 수정 가능
  • FE
    • 오늘의 집중 페이지 작업
    • setInterval, useState, useContext, useParams, useEffect 등 수업 시간에 배운 내용을 충분히 활용하기 위해 노력함
    • useLocation을 통해 state에 값을 전달하는 방식으로 url직접 접근을 제어함
    • framer-motion 라이브러리를 통해 요소에 애니메이션을 추가함
    • 매일 팀원들과 코드 리뷰 시간을 가짐 → 다양한 방식의 코드를 보면서 얻을 수 있는 점이 많음, 로직이나 객체, 배열 등의 사용을 보고 내 코드에도 적용할 수 있었음
    • 팀원들과의 코드 리뷰 시간을 위해 코드의 중복성을 체크하고, 주석처리를 하며 코드 정리를 함 → 코드의 가독성이 조금 나아지고, 수정사항 발생 시 접근하기 용이해짐
• Problem
  • BE
    • 동일한 수업을 듣고, 공통적으로 작업을 하니 겹치는 코드들이 보임 → 최대한 다른 코드들과의 비교를 통해 어떤 코드가 더 효율적인지 공부함
    • 사정 상 수업과 첫 회의에 불참하게 되어 진도를 따라가기 벅찬 부분이 있었음
    • 잘 이해되지 않는 부분이 있어 그 부분은 제외하고 코드 작성 (asyncHandler 등) → 다른 사람의 코드 리뷰 시간을 통해 배움
  • FE
    • 스스로 계획한게 아닌 주어진 내용을 보고 바로 작업하여 추후에 추가되는 로직들이 많아짐 → 이미 주요 기능들이 다 개발된 상황이라 테스트들을 통해 놓친 부분이 없는지를 확인하여 최대한 기존 코드에 방해없이 작업하기 위해 노력
    • 팀으로 있어도 각자 페이지를 개발하다보니 서로의 코드에 간섭하기가 어려워짐, 내 작업이 끝나면 다른 팀원을 도와주기 보단 내 공부를 위해 더 할게 없는지를 살펴봄 → 코드 리뷰 시간을 통해 서로의 코드를 자세히 뜯어보는 시간을 가지고, 페어 코딩을 통해 서로의 작업에 개입할 수 있는 시간을 가짐
    • 구상없이 코드를 짜 코드들이 지저분해지고 공통적으로 사용되는 부분이 있음에도 각각의 영역들이 개별적으로 짜여짐 → 공통적으로 사용되는 부분은 묶어서 함수처리 하고, 객체를 사용하여 상황에 맞게 변수를 줄 수 있게 처리함, 기본적인 계산 함수는 따로 파일을 만들어 묶어서 처리
    • 상세 스터디 페이지에서 오늘의 집중이나 오늘의 습관 페이지로 갈 때 비밀번호 확인 창이 있어야 하는데 url로 직접 접근 시 확인 절차가 없음 → url 접근과 페이지를 통한 접근이 구분되어야 된다고 판단, 페이지를 통한 접근 시 useLocation에 객체를 전달하여 url과의 차이점을 주어 제어함, router를 사용하여 비밀번호가 필요한 페이지와 그렇지 않은 페이지를 구분
• Try
  • 효율적인 스케쥴 관리 - 여유가 있다고 생각해 느긋하게 작업을 진행하다 예상치 못한 오류를 만나 시간이 꼬이기도 함
  • 라이브러리 사용 - 공부를 위해 직접 다 코딩하였지만 라이브러리를 사용하여 더 효율적인 코드를 작성할 수 있다고 생각
  • 코드 작성 시 정해놓은 규칙을 계속 상기해야 한다고 판단함 - 통합 과정 시 충돌을 줄일 수 있음

[Im-amberIm]

초급 프로젝트 회고록

문제점 단위로 3주간 노트했던것을 정리해봤습니다.
개발적 이슈 외, 팀 협업에서 팀 소통과 본딩이 중요 하다는것을 다시 한번 깨달았습니다.
여러시각을 가진 사람들이 팀으로 같은 방향을 바라보고 같은 페이지에 있다는게 핵심이였던것 같습니다.
결과의 성취보다 과정에서 즐겁게 같이 배운다는 느낌이 가장 보람찼던 경험이였습니다.

문제: BigInt Type 직렬화

• 프로젝트 진행 중, BigInt 타입을 JSON으로 직렬화할 때 TypeError: Do not know how to serialize a BigInt라는 에러가 발생함.
• JavaScript에서 BigInt 타입을 JSON으로 변환할 때 발생하는 문제.

해결책:

• 옵션 1: 앱 시작 파일 (app.js)에서 BigInt를 문자열로 변환

  BigInt.prototype.toJSON = function () {
    return { $bigint: this.toString() };
  };

  [MDN: 참고 링크](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt#use_within_json)

• 옵션 2: Prisma에서 BigInt 타입을 문자열로 변환하는 방법

  JSON.stringify(
    this,
    (key, value) => (typeof value === 'bigint' ? value.toString() : value)
  );

  [Prisma: 참고 링크](https://www.prisma.io/docs/orm/prisma-client/special-fields-and-types#serializing-bigint)

다른 문제점:

• BigInt 값을 문자열로 먼저 변환하면 숫자로 정렬할 때 문제가 생김. 정렬 후에 문자열로 변환하여 응답을 보내는 방식으로 해결함.

해결 방법:

• 옵션 1: map을 사용하여 BigInt 타입에 toString() 적용

  const bigIntToString = companies.map((company) => ({
    ...company,
    actualInvestment: company.actualInvestment.toString(),
    revenue: company.revenue.toString(),
  }));

• 옵션 2: JSON.stringify -> JSON.parse 방식 사용

  function bigIntToString(data) {
    return JSON.stringify(data, (key, value) => {
      return typeof value === "bigint" ? value.toString() : value;
    });
  }
  
  const parsedResult = JSON.parse(bigIntToString(company));
  res.send(parsedResult);

• 결과:

  • JSON.stringify만 사용할 경우, 응답의 Content-Type이 text/html로 설정되는 문제가 있어 이를 다시 JSON.parse로 처리하여 문제를 해결함.
  • 하지만 두 번 연산하는 것이 비효율적이라고 판단하여, map을 사용하는 방법을 선택함.
  • JSON.stringify를 사용하는 함수에서는 res.setHeader("Content-Type", "application/json");로 설정하여 parse를 사용하지 않아도 되도록 조정함.

---

문제: 테이블의 내용 줄임 표시 (ellipsis)

• 테이블에서 2줄 이상의 내용을 줄임 표시(...)로 나타내야 하는 문제 발생.

해결책:

• CSS를 사용하여 줄임 표시를 구현함.

  .TableRow .description {
    max-width: 301px;
    width: 100%;
  }
  
  .TableRow .description span {
    display: -webkit-box;
    -webkit-box-orient: vertical;
    -webkit-line-clamp: 2;
    overflow: hidden;
    text-overflow: ellipsis;
    white-space: normal;
  }

• 결과:

  • line-clamp를 사용하기 위해서는 블록 레벨 요소가 필요하므로, 이를 위해 td 내에 span으로 감싸서 -webkit-box 로 문제를 해결함. td는 블록레벨 요소나 -webkit-box같은 레이아웃 모델을 적용할수 없음.

  • 추가 설정:이 두 가지 속성을 함께 사용하여 ellipsis를 정상적으로 적용함.

    overflow: hidden;
    white-space: nowrap;

---

문제: 테이블의 첫 번째 컬럼이 타블렛 사이즈에서 display: none이 되며, border-radius도 사라짐

• 타블렛 사이즈에서 테이블의 첫 번째 컬럼이 display: none으로 처리될 때, 테이블의 왼쪽 (사라진 컬럼쪽) border-radius가 사라지는 문제 발생.

해결책:

• 테이블 thead와 tbody에 border-radius를 적용

  .Table thead tr th:first-child {
    border-bottom-left-radius: 4px;
  }
  
  .Table thead tr th:last-child {
    border-bottom-right-radius: 4px;
  }
  
  .Table tbody tr:first-child td:first-child {
    border-top-left-radius: 4px;
  }
  
  .Table tbody tr:first-child td:last-child {
    border-top-right-radius: 4px;
  }

---

문제: Pagination 요구사항 불일치

• 처음 api 계획짤때 cursor 기반 페이지네이션으로 정했지만, 디자인은 오프셋/리밋 기반으로 되어 있었음을 발견. 이로 인해 구현 방법에 대한 고민이 필요했음.

해결책:

• 토론 후 결론:
  • 오프셋 기반 페이지네이션으로 변경함. 주어진 디자인에서 쓰기엔 cursor 기반의 장점이 명확하지 않았고, 디자인과의 일관성을 유지하기 위해 이 방식을 선택함.
  • 만약 커서 기반을 유지할 경우, 미리 서버에서 5개 페이지 수만큼의 데이터를 조회해 cursor ID 배열을 제공해야 했기 때문에, (아니면 더 복잡한 로직 필요로) 커서 기반의 메리트가 없다는 결론에 도달함.

---

회고록 - Week 2/3

문제 1: 테이블 컴포넌트화의 어려움

각 테이블마다 필요한 필드와 렌더링 방식이 달라 공통 컴포넌트로 구현하는 것이 까다로웠음.

해결책:

• 유연한 렌더링 방식 도입:필드 종류에 따라 유연하게 렌더링할 수 있도록 설계해 다양한 테이블 구조를 지원함.
• Table 컴포넌트:list와 tableHeaders를 받아 동적으로 테이블을 생성하도록 설계함. 데이터 유효성 검사를 통해 list 가 없거나 잘못된 형식의 데이터를 처리하고, tableHeaders를 기반으로 thead와 tbody를 생성함. 각 셀은 TableData 컴포넌트를 통해 필드별로 다른 스타일과 기능을 지원하도록 했음.
• TableData 컴포넌트:각 셀의 데이터를 렌더링하며, header와 item을 받아 필드에 따라 적절한 렌더링을 수행함. 예를 들어, 기업명 필드는 로고와 링크를 표시하고, 투자 금액 필드는 포맷 변환을 적용함.
• ColGroup 컴포넌트:테이블 컬럼의 너비를 설정하는 역할을 함. columns를 받아 특정 필드는 고정 너비로, 나머지는 공통 너비로 설정해 일관된 레이아웃을 유지함.

개선점:

• PropTypes를 활용해 타입 체크를 강화할 필요가 있음.
• React-table 같은 라이브러리를 사용하는 것도 좋은 방법이라고 생각했음.

---

문제 2: 드롭다운 버튼의 공통화

드롭다운 버튼을 누를 때, 각 버튼에 맞는 정렬된 데이터를 API로부터 Fetch해야 했음. 이 과정에서 다양한 드롭다운 버튼이 존재하는데, 이들을 각각 공통 컴포넌트로 관리하면서도 각기 다른 동작을 수행하도록 구현하는 것이 도전이었음.

해결책:

• 드롭다운 버튼 컴포넌트화:

  테이블 컴포넌트에서 했던 것처럼, 필요한 3개의 버튼을 객체(value, label)로 정의하고, props로 버튼 타입(buttonType), 정렬 기준(orderBy), 정렬 상태 업데이트 함수(setOrderBy)를 받아 각 버튼이 고유의 동작을 수행하도록 설계함.

  • 정렬 상태 관리:sortBy와 order 두 가지 쿼리 파라미터를 orderBy라는 단일 상태로 관리함. 예를 들어, orderBy 상태를 "sort-by_order" 형식으로 업데이트하여, API 호출 시 이 값을 split하여 sortBy와 order로 분리해 사용하도록 함.

---

문제 3: 페이지네이션에서 무한 루프 문제

문제점:

페이지네이션 구현 과정에서 부모 컴포넌트 함수에서 totalPages를 계산한 후 페이지네이션 컴포넌트에 내려줄 때 무한 루프 API 호출이 발생했음.

queryParams state에서 totalPages를 같이 관리하면서, 이 값이 변경될 때마다 init 함수가 다시 실행돼, API 호출이 반복되는 무한 루프 상황이 발생했음.

해결책:

totalPages 값이 변경될 때만 상태를 업데이트하도록 조건문을 추가해 무한 루프 문제를 해결함. 새로운 totalPages 값을 기존 값과 비교해 다를 경우에만 상태를 업데이트하도록 함.

---

문제 4: 가로 스크롤바 커스텀 디자인

• 상황 설명:
  • 크롬에서는 커스텀 스크롤바 디자인이 잘 적용되었으나, 파이어폭스에서는 적용되지 않는 문제가 발생함.
  • 파이어폭스를 위한 CSS 코드(scrollbar-width 및 scrollbar-color)를 추가하였으나, 이로 인해 크롬의 스크롤바 디자인이 깨지는 현상이 발생.

해결책:

• 파이어폭스 전용 스타일링:
  • 파이어폭스의 경우 @supports를 사용하여 특정 CSS 속성 지원 여부를 확인한 뒤, 해당 속성을 적용함으로써 문제를 해결하려고 했으나, 크롬에서도 이 코드가 영향을 미치면서 디자인이 깨짐.
• 대안:
  • 브라우저별로 별도의 CSS 파일을 로드하거나, 특정 클래스명을 사용하여 브라우저에 따라 다른 스타일을 적용해야할듯. 그런데 firefox 호환까지는 생각안해도 된다 하셔서 그냥 무시하기로 함.

---

문제 5: Loader 애니메이션 만들기

• 상황 설명:
  • 커스텀 훅을 사용하여 load, error, api call 함수를 생성하는 과정에서 어려움을 겪음. 이해하는데 시간이 많이 소요 되었음.
  • CSS 애니메이션 구현 시, 로고의 i의 head 부분만 바운스되도록 애니메이션을 적용하려 했으나, 화면 너비가 바뀌면 원하는 위치에 정확히 맞추기 어려움.

해결책:

• i의 head 부분 바운스 애니메이션:
  • SVG에서 i의 head 부분을 지우고, 동일한 원형을 div로 만들어 애니메이션을 적용함.
  • calc() 함수를 사용하여 부모 요소의 절반을 기준으로 원형을 이동시킴으로써 화면 비율이 변경되어도 위치가 고정되도록 조정.

left: calc(50% - 75px);

top: calc(50% - 35px);

---

문제 6: 브랜드 이미지가 없을 때 사용할 디폴트 UI 생성 (LogoImg 컴포넌트)

• 상황: 브랜드 이미지가 없는 경우, 해당 브랜드를 대표할 UI를 생성해야 했음. 이를 위해, 배경색을 랜덤으로 생성하고 그 위에 브랜드 이니셜을 표시하는 방식을 고려함.
• 문제: 배경색을 랜덤으로 생성할 때, 밝은 색상이 선택되면 이니셜 텍스트(하얀색)가 잘 보이지 않는 상황이 발생함.

2. 초기 접근 방법:

• 랜덤 색상 생성: 먼저, 랜덤으로 HEX 색상 코드를 생성하는 방법을 사용함. 이를 통해 다양한 배경색을 쉽게 구현할 수 있었음.
  • 참고 자료:
    • [Random HEX Color Code Snippets](https://www.paulirish.com/2009/random-hex-color-code-snippets/)
    • [Generate Random HEX Color in JavaScript](https://dev.to/thecodepixi/what-the-hex-how-to-generate-random-hex-color-codes-in-javascript-21n)
• Contrast Ratio 계산: 배경색이 밝을 때 텍스트의 가독성을 위해, Relative Luminance를 사용해 텍스트와 배경 사이의 대비를 계산함. Luminance 계산을 위해 HEX에서 RGB로 색상 생성하는것으로 바꿈
  • 기존 공식:

    • L = 0.2126 * R + 0.7152 * G + 0.0722 * B

    • 이 공식을 사용하여 배경과 텍스트 색상의 밝기를 계산한 후, 대비 비율을 다음과 같이 구함:
      ContrastRatio=L2+0.05L1+0.05

      ContrastRatio=L1+0.05L2+0.05Contrast Ratio = \frac{L1 + 0.05}{L2 + 0.05}

    • 그러나, 이 방법이 실제 사용자 경험과 일치하지 않는 문제를 발견함. 포뮬라 이론상 W3 기준 4.5:1 대비 비율에 만족하지만, 실제로는 텍스트가 잘 보이지 않는 경우가 있었음. 알고보니 outdated된 포뮬라였음.

3. 새로운 접근법:

• 문제: 기존 Relative Luminance 기반 대비 계산 공식은 실제 사용자의 시각적 인지와 일치하지 않았음. 특히, 밝은 배경과 어두운 텍스트 조합에서 이러한 문제가 더 두드러졌음.
• 새로운 접근법: 더 정확한 대비 계산을 위해 Advanced Perceptual Contrast Algorithm (APCA)를 써야 한다함
  • APCA:
    • 설명: APCA는 기존 대비 계산 방식과 달리, 글꼴 크기, 굵기, 색상 조합 등을 고려하여 더 현실적인 대비를 계산함.
    • 공식: APCA는 색상의 밝기를 지수 함수로 변환하여 더 정확한 대비를 계산하며, 텍스트 크기와 굵기에 따라 요구되는 대비 수준을 동적으로 조정함.
    • 참고 자료: [APCA 설명 및 구현](https://www.w3.org/WAI/GL/task-forces/silver/wiki/User:Myndex/APCA_model) (계산식)
    • 일단 여기서 이거 하나 구현하는데 함수를 너무 많이 사용하고 집착하는거 같아서 살짝 식음..(너무 복잡해서 사용에 부담느낌) 이렇게 까지 할 일이 아닌거 같음;

4. 문제 해결 및 한계:

• 최종 해결책:
  • 생각해보니 어차피 테이블이 재 랜더링 될때 무작위로 또 배경색이 부여되서 디자인 일관성이 사라짐.
  • 데이터베이스 수정: 이를 해결하기 위해, 팀 회의후 데이터베이스에 brandColor 필드를 추가하여, brandImage가 없는 경우 brandColor를 사용해서 디폴트 로고를 만들기로 함.
  • brandColor enum(6종류의 색상)으로 mockup seeding 할때 랜덤으로 색상 넣어줌.
  • Contrast Ratio 확인: 어도비 색상대비 툴 사용해 주어진 배경색상에 최소 8:1의 대비를 되는 색상을 골라 프론트에서 텍스트 색상을 매칭해줌.

5. 개선점 및 향후 계획:

• 해쉬 함수 사용: 해쉬 함수를 사용하여 입력값에 따라 일관된 배경색을 생성하는 방법을 추천받음. 이렇게 하면 백엔드 수정 없이도 일관된 배경색을 유지할 수 있다함.
  • 개선및 하고싶은점: 연습으로, APCA 포뮬라를 사용해 랜덤 배경색을 지정하고, 그 배경색과 대비되는 텍스트 색상을 부여하는 기능을 구현해보고 싶음. 원래는 배경색의 베이스 컬러가 섞인 대비되는 텍스트 색상을 자동으로 생성하고 싶었음.
  • 해쉬 함수를 사용해 일관성을 유지하는 방법을 실습해 보는거 좋을거 같음.

---

문제 7: 테이블 내 모달의 리렌더링 문제 해결 과정

프로젝트에서 테이블 셀 내에 모달을 렌더링하는 과정에서 문제가 발생했음. 이 모달은 순위가 올라갈 때는 정상적으로 동작했지만, 순위가 내려갈 때만 모달(dialog)의 backdrop이 제대로 적용되지 않는 문제가 있었음. 이 문제는 특히 테이블 셀 내부에서 발생하는 리렌더링과 관련이 있었음.

2. 초기 접근 및 실패

문제를 해결하기 위해 두 가지 접근을 시도했음:

1. key 속성 사용:
   • React의 key 속성을 이용해 모달이 리렌더링될 때 새로운 컴포넌트로 인식되도록 시도했지만, 근본적인 문제를 해결하지 못했음. 특히, 순위가 내려갈 때 발생하는 특이한 문제는 여전히 존재했음.
2. 부모 컴포넌트에서 상태 관리:
   • 모달을 부모 컴포넌트에서 상태로 관리하여 props로 전달하는 방식도 고려했음. 그러나 모달을 부모 컴포넌트에서 내려주는 방식은 드릴링이 심해지는 문제가 있었음. 이로 인해 코드 복잡성이 증가하고, 유지보수성이 떨어질 우려가 있었음.

3. 최종 해결책: ReactDOM.createPortal 사용

이 문제를 해결하기 위해 ReactDOM.createPortal을 사용하기로 결정했음. 이 방법을 통해 모달을 DOM의 최상위 레벨(document.body)로 이동시키고, 테이블 셀 내부의 리렌더링 문제에서 벗어날 수 있었음.

이 접근이 효과적이었던 이유는 다음과 같았음:

• 순위가 내려갈 때 발생하던 문제가 완전히 해결되었음. 모달이 테이블의 다른 요소들로부터 독립적으로 동작하게 되었음.
• 모달의 backdrop이 항상 올바르게 적용되었고, 테이블의 리렌더링과 무관하게 UI가 안정적으로 유지되었음.
• 부모 컴포넌트에서 상태를 내려주는 방식 대신 createPortal을 사용함으로써 드릴링 문제를 해결할 수 있었음. 코드가 더 간결하고 유지보수하기 쉬워졌음.

4. 결과

createPortal을 적용한 결과, 모달이 테이블 셀 내부의 리렌더링에 영향을 받지 않게 되었고, 순위 변화에 따른 문제도 완전히 해결되었음.

5. 교훈 및 향후 개선점

• ReactDOM.createPortal은 특히 복잡한 컴포넌트 구조에서 드릴링 문제를 피하고 UI를 독립적으로 유지하는 데 유용한 도구임을 알게 되었음.
• key 속성이나 부모 컴포넌트에서 상태를 내려주는 방식이 항상 최선이 아닐 수 있으며, 구조적인 문제는 근본적으로 접근 방법을 바꿔야 해결될 수 있음을 깨달았음.
• 복잡한 UI 문제를 해결할 때는 다양한 방법을 시도하되, 가장 효율적인 해결책을 찾는 것이 중요하다는 점을 배웠음.

[Accreditus]

Keep

• 팀원과의 직간접적인 코드교류의 횟수를 늘리는것으로 코드구조의 일관화 달성
• 유연한 일정과 구체적인 마일스톤 계획으로 작업일정의 계획을 보다 수월하게
• 팀원의 요구사항 파악

Problem

• 코드의 최적화 미숙으로 낭비되는 리소스 및, 불필요한 API요청, 렌더링이 발생함

Try

• 코드를 짜는것도 좋지만 최적화에 보다 많은 시간을 투자하는게 좋아보임

[TradeOffEgoist]

• 1. 유지할 점 (Keep)
  • 지속적인 소통 및 피드백이 프로젝트 성공의 핵심이라 생각합니다. 보다 적극적인 소통을 지향하겠습니다.
• 2. 문제점 (Problem)
  • 코드 작성에 있어 유지 보수를 고려하지 않아 디버깅에 있어 큰 어려움이 있었습니다. 보다 엄밀한 학습을 통해 개선 하겠습니다.
• 3. 시도할 점 (Try)
  • 다른 팀에서 이모지를 사용한 커밋이 정말 인상 깊었습니다. 보다 원활한 소통을 위해 다음에 있을 프로젝트에서 사용하고 싶습니다.