토론 커뮤니티 Web 회고(w. React, Team Project)

토론 커뮤니티 Web 만들기

정말 오랜만에 회고를 작성하는 데 어떻게 작성을 해야 할 지 감이 잘 잡히지 않아 그냥 생각의 순서에 따라 작성을 해보겠습니다.

3주 정도의 시간으로 4명의 프론트 엔드 개발자님들(저 포함 ^^)과 함께 토론 커뮤니티 Web을 제작하였습니다.

시작에 앞서 프로젝트에 대해 간단하게 소개를 하자면

엄마가 좋아? vs 아빠가 좋아?

SNS, 방송을 중심으로 깻잎, 새우 논쟁 등 다양한 의견이 있는 간단한 논쟁들을 쉽게 투표하고 의견을 나누는 토론 커뮤니티 서비스 입니다.

Github: https://github.com/prgrms-fe-devcourse/FEDC2_ToronTo_Nayoung
배포: https://melodic-fenglisu-afc3b8.netlify.app

정말 멋있는 프로젝트이니 들어가서 확인해보시면 좋습니다.
많은 기술적인 문제 등 여러 문제를 발견하고 해결을 하였지만 가장 기억에 남은 부분 몇 가지만 다룰려고 합니다.

 

🧑🏻‍🏫 초기 문서화?! 기획?!

처음에 문서화의 중요성에 대해 멘토님들에게 많이 들어 저희 나름대로 문서화를 진행하게 되었습니다.

초기에 회의 시간을 줄이고 작업을 효율적으로 처리하기 위해 나름의 규칙과 회의 폼(안건, 회의, 결과)을 만들어 회의 문서를 작성하였습니다.

- 안건
- 회의 
- 결과

처음에는 '괜찮게 잘 가고 있구나' 라고 생각했으나!!!

정리하는 데 시간이 많이 걸리고 깔끔한 정리가 되지 않아 jira 라는 Tool을 사용하여 각자 할 일에 대한 것을 적고 회의를 진행하는 식으로 하였습니다.

처음 사용하는 Tool 이라 겁을 먹었지만 Github의 Project 부분과 매우 비슷하게 jira에서도 To Do -> In Progress -> Done과정으로 관리를 하였습니다.

초기 기획을 보면

- 멤버의 역할(업무 분담 / Page 별로)
- 프로젝트 주제
- 기술 스택
- 코딩 컨벤션(Github, component, 코드 포맷팅)
- 일정 계획

다음과 같이 작성하였습니다.

1. 프로젝트 주제 정하기

프로젝트를 진행하는 시간이 부족하여 편하게 팀원 들끼리 하고 싶은 주제에 대해 의견을 막!!! 제시하고 그 중에서 결정하는 식으로 정하게 되었습니다. 시간을 넉넉히 잡고 사회적 문제관련해서 주제를 정했으면 하는 아쉬움이 남습니다.

2. 기술 스택 및 코딩 컨벤션

'어떤 기술을 사용할지?' '어떤 규칙에 맞춰서 코드를 짤지?'를 정해야 했습니다.
기본적인 IDE, React, storybook, Figma, Github 등은 다들 비슷하게 사용해서 통일이 되었지만 다른 것들은 통일이 필요했습니다.

• 패키지 관리 npm or yarn
  기본적으로 사용해왔던 npm을 사용하자 vs 개발자 분들이 많이 사용하는 yarn을 사용하자
  로 나뉘었는데 각 패키지 관리의 장/단점을 파악하기 위해 자료를 찾아본 결과 병렬로 설치하여 속도가 좋은 yarn을 사용하기로 했습니다.
• 프로젝트 관리 Github or jira
Github의 Project를 사용하려 했지만 한 팀원이 '필드에서는 jira를 많이 사용하고 좋은 장점들이 많다'라는 의견과 jira Page을 보고 전반적인 작업 관리에 더 적합해 보이는 jira를 사용하면 좋아 선택하게 되었습니다. 그러나 생각 보다 jira의 많은 기능을 사용하지 못한 점이 아쉽기는 합니다.
• Style 관리
  기본 환경 설정을 하면서 파일, 폴더 구조, 코드 포맷팅(ESLint, Prettier)을 생각하였습니다.
  기본적으로 React를 사용하기 때문에 create-react-app와 Storybook을 같이 사용하여 기본 설정하였고 배운데로 적용하려 했습니다. 코드 스타일은 각자 원하는 부분을 말하고 절충안을 찾아 정하게 되었고 개발을 하면서 필요한 부분이 있으면 회의 후 추가하는 식으로 결정하였습니다.
• Git flow 전략 및 PR
  각자 feature/*로 이름으로 개발을 한 후 develop에 PR을 날려 2명 이상이 코드를 확인하면 develop에 merge하고 배포할 때는 develop를 release로 가져와 배포 테스트를 진행한 후 완료가 되면 main으로 날리는 git-flow 방식을 선택하여 사용하였습니다.
  빠르게 개발을 해야해서 PR인원 수에 대해 고민을 했지만 다시 다 뜯어 고치는 시간보다 확인하는 시간이 적다고 판단이 되어 최소 2명을 기준으로 잡게 되었습니다.

3. 업무 분담

개발 업무를 분담을 어떻게 할지 고민을 했지만 분리하기 쉬운 방법이 Page 별로 분담하는 것이라고 생각이 들었습니다. 그래서 다음과 같이 각자 필요한 Page에 대해 생각을 하고 생각을 합친 후 Figma에 작성하여 분담하였습니다.
(초기 나의 것,,,, 너무 허접하다)

그리고 빨리 끝난 팀원들은 수시로 소통을 하며 최종 기한에 개발을 완료할 수 있게 다른 팀원들의 업무를 나누도록 하였습니다.
그러나 개발을 하면서 공통으로 사용 되는 부분(component, ...)이 많았고 각 Page마다 연관성있는 부분을 쪼개는 데 시간이 꽤 들었습니다. 그래서

업무 분담은 Component 별 + 연관성을 파악하여

라는 생각을 가지게 되었고 다음 프로젝트를 진행 할 때 더 적용시켜 봐야겠습니다.
그래도 적극적인 팀원들과의 많은 소통을 통해 해당 문제를 생각보다 빠르게 해결했다는 점에서 소통의 중요성을 다시한번 깨닫는 시간이었습니다.

4. 일정 계획

사실 일정은 1차기획, 중간, 최종으로 나누어져 있어

- 개발
- 배포
- 서류 준비

을 주로 생각하였습니다.
정해진 일정 하루 전에 서류 준비기간을 잡고 3/2 정도 개발을 진행하고 2일 정도 배포의 시간을 가지면 되겠다 했지만 하다보니 예상보다 개발, 배포 시간이 부족하여 미뤄지는 현상이 발생하여 다음에는 예상 시간보다 최소 3일은 더 잡고 일정 계획을 짜야겠습니다.

 

🧑🏻‍🏫 무서운 API

위의 에러..., CORS 문제등등등 많은 문제가 있었지만
가장 큰 문제는 정해진 Api에서 원하는 Web사이트를 만드는 것이었습니다.
특히 postId등 Id를 넣는 곳에 undefined를 넣으면 서버 펑!!! 멘탈 펑!!!
=> 꼭 Dummy Data를 사용하게 된 것 같습니다. 하하하

해당 Api가 SNS에 초점 맞춰져 있으며 한 분이 여러 팀의 Api 전체를 관리하다 보니 수정이 어려워
Api를 Custom을 해야 했습니다. 이를 통해 백엔드 분들과도 절충안을 찾는 것이 매우 중요하겠다 라는 생각을 가지게 되었습니다.

그래도 저희가 원하는 결과를 내기 위해 Api를 커스텀 하였고 다음과 같이 계속해서 변경해나갔습니다.

질문을 하면서 '나는 많이 봐서 간단하게 설명해도 잘 알 수 있는데 다른 이는 알기 힘들 것 같다' 라는 생각이 들어 질문의 중요성을 깨달아 다음 양식을 기본으로 질문을 하려 하고 있습니다.

- 질문 정리
- 해본 시도
- 질문에 대한 해결책(나만의)

 

🧑🏻‍🏫 Netlify Serverless: 숨어라 변수

-> API Key등 중요 값이 노출되는 것을 막기위해 Serverless함수로 작성

이라는 목적을 가지고 작업을 진행하였습니다.

1. .env 작성

가리고 싶은 값들을 정의했습니다.

REACT_APP_API_END_POINT='https://~~~~~'
...

2. Netlify의 functions에 함수 작성

다음과 같이 Serverless 함수를 작성하는데 문제가 발생했습니다.

> 첫번째 문제: event에 무엇이 들어오는지 context에 무엇이 들어오는지 파악 X <

특이점이 functions/request.js 부분에서 console.log를 찍어 볼 수 없는 문제가 있었습니다.
이 부분은 return 값을 잘 조작하여 확인하였습니다.

이 과정에서 stackoverflow, 여러 블로그등을 보면서 문제를 해결하려 했지만 정확하지 않은 부분들도 많아 빙빙 돌았던 것 같습니다.
이 때 Netlify의 공식문서에서 다음과 같은 구조를 한번에 파악을 할 수 있었습니다.

{
  "path": "Path parameter (original URL encoding)",
  "httpMethod": "Incoming request’s method name",
  "headers": {Incoming request headers},
  "queryStringParameters": {Query string parameters},
  "body": "A JSON string of the request payload",
  "isBase64Encoded": "A boolean flag to indicate if the applicable request payload is Base64-encoded"
}

너무 천사같은 것 이였습니다.

공식 문서 부터 보자

> 두번째 문제: 각자 다른 api 연결 방식 + 페어 프로그래밍<

각 Page를 제작하면서 Page마다 사용하는 Api가 다르고 사용하는 방법도 각자 달랐습니다.
그래서 이 부분을 Serverless를 제작하면서 통일 시키려 했습니다.(다음에는... 초기에 정해두고 해야지....)

그래서 이때부터 페어 프로그래밍을 시작하게 되었습니다.

둘다 Navigator, Driver 역할을 같이 하였지만 전략을 제시하는 Navigator 역할을 더 많이 했습니다.
이 때 약간의 피로도가 있었지만 수시로 결과를 확인하고 문제 발생시 같이 고민하여 빠르게 문제를 해결 할 수 있었으며 빠르게 Api구조를 결정지어 효율이 좋은 경험었고 팀원의 노하우, 스타일등을 파악하는 데 도움이 되어 추후 작업에 속도를 더 하며 검색 스킬등 나의 장점도 찾게 되는 정말 좋은 경험이었습니다.

이로 인해 만든 결과물 입니다.

//functions/request.js
const  axios = require('axios');

exports.handler = async  function (event) {
const { url, method, body, headers } = JSON.parse(event.body);
  try {
    const res = await  axios({
    url: `${process.env.REACT_APP_END_POINT}${encodeURI(url)}`,
    method,
    data: body,
    headers,
    });
  return {
    statusCode: 200,
    body: JSON.stringify({
    data: res.data,
    }),
  };
  } catch (e) {
    return {
      statusCode: 404,
      body: JSON.stringify({
      e,
      }),
    };
  }
};

//위의 코드와 연결하는 부분
export  const  serverless = async (options) => {
  try {
    const  res = await  fetch(`/.netlify/functions/request`, {
      method:  'POST',
      body:  JSON.stringify(options),
    });
  return  await  res.json();
  } catch (e) {
    throw  new  Error(e);
  }
};

> 세번째 문제: FormData 연결<

와..... 이 부분이 대박 이었습니다.
처음 목표는 FormData를 "body": "A JSON string of the request payload"를 통해서 전달하는 것이였습니다.

그런데 FormData -> JSON string으로 변환을 시키니 값이 없어지는 문제가 발생하였고
'왜 이럴까?' 라는 의문을 가지고 여러 곳을 찾아보니 크기가 너무 커서 값이 없어지는 것일 수 도 있다는 가벼운 답을 찾았습니다.
이를 가지고 FormData에 들어가 있는 값중 가장 큰 값인 Image부분의 크기를 URL, Base64로 줄여서 전달을 해서 잘 받아 Serverless부분에서 변형을 시켜 해보니.... 안된다.... 하하하하
(가볍게 적었지만 라이브러리, 함수등 2일동안 갈았습니다.....)

결국 질문을 했습니다....
https://stackoverflow.com/questions/54939397/how-to-hide-data-from-network-tab
함께 날라 온 왜? 이렇게 해?

이 때 정말 FormData에 대해서 쪼개도 보고 Netlify도 쪼개보려 하고 했는데 정말 허탈했습니다.
그래서 문제가 발생했을 때

해결가능한 문제인지 확인

하고 더 파볼려고 합니다. :) 보통 다 되어서 그냥 했는데 허허허

 

마치며

이번 프로젝트는 생각보다 기술적인 부분보다 팀플이 기억에 많이 남는 프로젝트여서 이렇게 회고를 작성하게 되었습니다.
기술적인 문제에 관해서는 추후 블로그로 작성을 하여 자세히 정리를 해보도록 할 것이고 팀플에 대해 많이 깨달은 만큼 더 발전해야 겠습니다. :)

그리고 팀원들 끼리 프로젝트를 하면서 느낀점을 적어주어 이것을 보고 더 발전하는 팽건우가 될 것입니다.

긴 글 읽어주셔서 감사합니다.

 

멘토님 피드백

REF

프로그래머스