project : Chap-Chap

Chap-Chap(챱챱)은 mobithon 기간에 진행한 토이 프로젝트로, open API를 활용해 레시피를 검색하고 스크랩할 수 있는 사이트입니다.

• 프로젝트 진행 기간 : 2024.01.19 ~ 2024.01.28
• 리팩터링 기간 : 2024.01.30 ~ 2024.02.01

약 10일동안 진행된 프로젝트 Chap-Chap을 통해 제가 확실히 얻고 싶었던 포인트는 두 가지였습니다.

1. 이전 프로젝트에서 엉성했던 협업을 다지기
2. 타입스크립트와 친해지기

이전 프로젝트 MMM에서 보완이 시급했던 협업과 저번 주에 처음 접한 타입스크립트의 사용이었습니다.
협업의 필요성은 이전 회고에서 절실히 느꼈던 부분이고, 타입스크립트는 다음 주에 Next.js와 함께 사용을 해야 하기 때문에 친해질 필요가 있습니다.
주로 사용되는 타입들을 간단한 예시와 함께 볼 땐 이해도 잘 되는 것 같고 당장 사용하기 괜찮은 것 같지만 막상 간단한 회원가입/로그인 폼(form)에 적용하려고만 해도 금방 막연하게 느껴졌습니다. 그래서 이번 토이 프로젝트를 통해 타입스크립트와 조금 더 친해지는 것이 두 번째 목표였습니다.

---

역할 분담은 planning-poker(플래닝 포커) 방식으로 진행했습니다.
플래닝 포커로 담당자를 정해 각자 맡은 페이지를 진행하지만 blocking이 오래 지속되는 경우 함께 해결했습니다.

플래닝 포커, 혹은 스크럼 포커는 그룹 구성원들이 테이블 위에 숫자가 적힌 카드를 뒤집어 놓고 동시에 카드를 뒤집어 노동시간을 계산하는 노동시간 계산법 중 하나 입니다. James Grenning이 창안했으며 애자일 개발 이론에 사용됩니다.

저희는 검색했을 때 나오는 피보나치 수열의 카드를 가지고 하는 방법이 아닌,
"내가 이 페이지를 진행한다면 어느 정도의 시간이 걸릴 것인가, 나에겐 어떤 난이도인가"를 두고 포커를 진행했습니다.
배팅은 1~100까지 가능하며 가장 적게 배팅한 사람이 해당 프로젝트를 진행하게 됩니다. 단, 다음 프로젝트의 담당자를 정할 때는 누적으로 계산합니다.

얼마나 걸릴지 TypeScript + tailwindCSS 를 처음 적용해보는 프로젝트이기에 정확한 배팅을 하기 어려웠기에 특별히 많이 차이가 나지 않는 부분은 해당 파트를 경험해보지 않은 팀원에게 배당했습니다.

Designing... 🎨

아래와 같이 BDD(Given-When-Then)로 기획을 한 후 이를 토대로 디자인을 진행했습니다.

식욕을 돋울 수 있는 난색들 중 노란색을 main-color로 설정해 진행했습니다.
디자인은 타입스크립트와 호환성이 좋은 tailwind-css를 사용했고 애니메이션을 적극 활용했습니다.

Auth 관련 로직은 Kimi 님이 맡은 파트였습니다. 타입스크립트를 막 배우고 처음 제대로 활용하는 상태에서 복잡한(난해한?) 애니메이션을 하게 되어 많은 어려움을 겪었는데 끝까지 포기하지 않고 진행해주셔서 구현할 수 있었습니다 :)

약 이틀동안 퍼블리싱 과정을 끝내고 개발에 들어갔습니다.

---

Developing... 💻

어떻게 하면 에자일해질 수 있을까?

협업툴 사용하기 : Linear

Linear를 사용해 backlog를 생성해 맡은 파트를 할당했습니다.
아래와 같이 My issues를 통해 내 task들을 진행 과정으로 나눠 확인할 수 있습니다.

다른 팀원들의 진행 정도도 볼 수 있고 전체 진행 퍼센트 확인도 가능합니다.
무엇보다 gitHub의 repository와 연동할 수 있어 자동으로 backlog의 상태가 변경됩니다.

또한 브랜치의 이름을 정할 시간을 줄일 수 있습니다 :)
MMM 때 리팩터링까지 진행하다보면 branch 이름에 '/'(슬래시)가 너무 많이 들어가
길어지고 컨벤션에 맞지 않게 생성되는 경우도 있었는데 이 경우는 프로젝트 이름을 토대로 자동 생성해주기 때문에 위와 같은 문제가 발생하지 않습니다.

daily-scrum은 git issue로

처음에는 Jira로 데일리스크럼을 쓰면서 진행을 했는데 좀 불편했습니다.

새로운 사이트를 들어가 작성하고 git을 pull 받아 진행하는 과정이 번거롭게 느껴졌고, Jira는 Linear처럼 사용할 수 있는 툴이기 때문에 두 개를 동시에 사용하기보다는 둘 중 하나를 택해 사용하는 것이 일반적이라는 피드백도 받았습니다.

그래서 git issue에 label을 활용해 데일리스크럼을 쓰기 시작했습니다.
이렇게 진행하니 확실히 다른 팀원의 todolist도 바로바로 확인할 수 있었습니다.

git issue에서 아래와 같이 나누고 싶은 의견이나 blocking된 부분 공유도 하고 있었기에 이전보다 빠르게 follow-up이 가능해졌습니다.

나아가 blocking 되어 PR을 못하게 될 경우 1일 1commit 규칙을 지키지 못할 수 있다는 부담을 issue 등록을 통해 완화할 수 있다는 장점도 있습니다.

✔️ issue 생성 시 commit 수가 늘어납니다.

PR Template로 상세한 코드 설명과 꼼꼼한 코드 리뷰

저희는 아래와 같은 template을 적용했습니다.
먼저 간략히 전체적인 PR의 내용을 요약하고 유형을 선택합니다.

직접 만든 함수의 경우 다른 사람이 사용하거나 이해하기 편하게
JS DOCs와 sample 그리고 PR에 설명을 통해 서술하도록 했습니다.

detail에는 내가 공유하고 싶은 코드의 일부를 발췌해 설명할 수 있도록 했습니다.
코드 설명 후에는 진행 예정인 부분을 적을 수도 있고 막히는 부분을 적을 수도 있습니다 :)

// PR template
## 개요

<!-- 한 줄 요약 -->

## PR 유형

어떤 변경 사항이 있나요?

-   [ ] 🟢 feat : 새로운 기능 추가
-   [ ] 🔴 Remove : 파일이나 폴더를 삭제하는 작업만 수행한 경우
-   [ ] 🔥 HOTFIX : 급하게 치명적인 버그를 고쳐야하는 경우
-   [ ] 🐞 fix : 버그수정
-   [ ] 🎁 style : CSS 등 사용자 UI 디자인 변경
-   [ ] 💬 Comment : 필요한 주석 추가 및 변경
-   [ ] 💡 refactor : 기능, 코드 개선
-   [ ] 🔖 Rename : 파일 혹은 폴더명을 수정하거나 옮기는 작업만인 경우
-   [x] 📂 docs : 문서 수정


## PR Checklist

PR이 다음 요구 사항을 충족하는지 확인하세요.

-   [ ] 커밋 메시지 컨벤션에 맞게 작성했습니다.
-   [ ] 직접 만든 함수가 있다면 이에 대한 설명을 추가했습니다. (ex. JS DOCS)
-   [ ] 변경 사항에 대한 테스트를 했습니다. (버그 수정/기능에 대한 테스트)


## PR details

<!-- 변경 사항 및 관련 이슈에 대해 간단하게 작성해주세요. 어떻게보다 무엇을 왜 수정했는지 설명해주세요. -->
<!-- 직접 만든 함수가 있다면 예제를 만들어 상세히 설명해주세요. (코드 캡쳐) -->

타입스크립트로 훅함수 만들기

적용하기 쉽도록 JS Docs도 적었습니다.
sample은 제가 이미 만든 후 적용한 페이지가 있어 생략했습니다.

/**
 * @function useGetRecipeInfinity 는 recipe data를 가져와 무한 스크롤을 구현해주는 hook 함수
 * @param {recipeData} : 매개변수로 받은 데이터들을 스프레드 형태로 보관, api 주소에 저장
 * @param {fetchNextPage} : useInfiniteQuery의 options 중 하나
 * @return {recipeData, fetchNextPage}
 **/

export function useGetRecipeInfinity() {
  const {
    data: recipeData,
    fetchNextPage,
    hasNextPage,
    isFetching,
  } = useInfiniteQuery({
    queryKey: [QUERY_KEY.MORE_RECIPE_LIST],
    queryFn: ({ pageParam = { startIdx: 1, endIdx: 12 } }) =>
      getRecipe(pageParam),
    getNextPageParam: (lastPage, totalPages) => {
      const startIdx = totalPages.length * 12 + 1;
      let endIdx = (totalPages.length + 1) * 12;

      if (lastPage.COOKRCP01.total_count < endIdx) {
        endIdx = lastPage.COOKRCP01.total_count;
      }
      if (startIdx > lastPage.COOKRCP01.total_count) {
        return null;
      }
      return { startIdx, endIdx };
    },
  });
  return { recipeData, fetchNextPage, hasNextPage, isFetching };
}

추가적으로 hook 함수를 만든 후 PR할 때 상세한 설명을 첨부했습니다.

꼼꼼하게 PR을 작성하고 다른 팀원을 위해 JS Docs를 적다보니 이건 저를 위해서도 좋다는 것을 자연스럽게 알게 되었습니다.

제 코드를 적을 때 설명을 적다보니 리팩터링할 부분도 더 잘 보여 내 코드의 문제를 빠르게 파악할 수 있었습니다. 설명과 주석을 달다보면 이름도 더 직관적으로 이해 가능하도록 바꾸게 되었습니다.

infinite-query 부분은 여러 프로젝트에서 재사용될 수 있으므로 다음 프로젝트에서 더 재사용하기 용이하도록 바꿔보려고 합니다 :)

---

🔗 Links

figma 👉 더 자세한 디자인은 피그마 링크에서 확인하기
vercel 👉 구현된 사이트에서 편하게 확인하기

본 사이트는 1920px 기준으로 디자인되었으며 반응형이 적용되어 있지 않습니다.

🧪 테스트 계정

account info
ID	chapchap
password	chap1234

---

Memoirs 💬

| 에자일(Agile)해졌는가?

협업을 위해 저희 팀 yeong-cha(영차)는 PR template을 사용해 꼼꼼히 내가 짠 코드를 다른 팀원들이 이해할 수 있도록 했습니다. 템플릿을 통해 통일성 부여도 할 수 있고 어떤 내용이 담겨 있을지 미리 파악이 가능하기 때문에 다른 팀원이 짠 코드를 이해하는데 전보다 훨씬 수월했습니다.

직접 만든 함수가 있다면 반드시 설명과 예시를 적을 수 있게 이에 대한 체크 여부도 PR template 내용에 추가했습니다.

막히는 부분이나 고민이 되는 부분은 github issue를 통해 의견을 나눴고 모든 게시된 글들(issue 및 PR)의 comment는 최대한 성심성의껏 작성했습니다.

Linear라는 협업툴을 사용해 back-log도 확인할 수 있도록 했고, daily scrum은 github issue에 적어 다른 사이트 방문 없이 편하게 서로의 일정을 파악할 수 있도록 했습니다.

지난 프로젝트에서 놓친 부분을 보완해 나가면서 에자일하게 프로젝트를 진행하게 되면 상당 비용이 든다는 것을 알았습니다. 하나의 PR에 review를 시작하면 최소 1시간이 걸렸기 때문입니다.
하지만 이런 비용을 들여야지만 유지보수하기도 용이하고 코드에 대한 이해도 높아진다는 것도 함께 알게 되었습니다.

이전에는 리팩터링을 진행할 때 비로소 다른 페어가 짠 코드를 면밀히 살펴보게 되었기 때문에
시간도 오래 소요되고 코드의 통일성도 떨어졌는데 이번에는 확실히 이러한 부분들이 개선되었습니다.

code review를 통해 지켜지지 않은 부분들을 수정하고 merge할 수 있었고,
피드백을 통해 즉각적으로 코드 개선이 가능했습니다.

이전에는 각 페어가 돌아가며 한 번씩 리뷰를 진행했기 때문에 내가 보지 못한 PR이 존재했습니다.
이런 부분을 없애기 위해 모든 팀원이 리뷰를 하고 승인해야 하고 코드의 주인이 댓글을 달아야만 merge할 수 있도록 강제성도 부여했습니다.

협업을 신경쓰다보니 개발 시간이 더 걸리는 것 같지만 유지보수 측면 등을 고려해 멀리 내다보면 오히려 생산성이 있는 쪽은 협업을 신경쓰는 프로젝트임을 확실히 짚고 넘어갈 수 있는 계기가 되었습니다.

| 이번에 아쉬웠던 점은 ?

개발을 하는 과정에서 API 분석에 대한 아쉬움이 있었습니다.
제대로 분석을 하지 않아 구현할 수 없는 기능들을 구현하려고 시간을 쏟았기 때문입니다.

예를 들어 이번 프로젝트에서 scrap 기능과 filter 기능이 해당됩니다.
스크랩은 mobithonAPI에서 내가 스크랩한 게시글인지 확인할 수 있는 기능이 없어 구현할 수 없었고, filter는 openAPI에서 관련 기능을 제공해주지 않아 프론트 단에서 하드코딩을 해야 했습니다.

미리 API 분석을 더 꼼꼼히 했다면 안 되는 기능을 붙잡고 끙끙거리지 않았을 것이라 생각되었고, API 분석을 확실히 짚고 넘어가기 위해 바로 다음 토이 프로젝트를 기획했습니다.

전반적으로 API 분석이 미흡했던 탓에 완성을 하지 못했지만 처음부터 저희의 1순위 목표는 협업과 성장이었기 때문에 나름 성공적인 프로젝트였다고 생각합니다.

부족한 부분은 다음 프로젝트에서 채울 예정이기 때문에 아쉬움보단 같이의 가치를 알수 있는 기회가 되었다고 생각합니다.

좋은 협업 문화를 함께 만든 조원들 덕분에 잠도 제대로 못 자며 진행했지만 즐거운 시간으로 기억될 것 같습니다. 다음 프로젝트도 같이 진행하는 Kimi 님은 한 번 더 잘 부탁드리고, 복습을 진행하기로 결정하신 Ann 님은 옆에서 응원하고 있겠습니다🩷