프로젝트(멘토) 회고록 #2

내 질문

1. 커밋 & 푸시 & 머지 시점

다른사람들과 같이 작업을 하다보니 혼란이 왔다. git log를 봤는데 다른 브랜치에서 pull해서 그런지 다 들어있는...(심지어는 백엔드 로그까지!)
근데 이게 정상이라고.

커밋을 날리는 시점

UI 마크업이 다 됐을때 등 작은 단위의 작업이 완료되었을때.
커밋은 나중에 문제가 발생했을때 원복할 수 있는 시점이다.

푸시

기능이 모두 개발되었을때

머지 & 풀

아침이나 저녁쯤 스탠딩미팅 시간을 가지면서 완료된 기능이 있으면 그때 풀하라고 조언.

더 얘기를 나누어보니
머지는 개발이 완료되었을때 하고, 머지가 되었다는 것은 오류가 없다고 합의를 했다는 의미이다.
머지된 브랜치는 이제 닫는다고 보면 됨.
만일 머지했는데 문제가 발생한다면 다시 돌리려고 하기보다 다른 브랜치를 만들어서 해결하는 게 좋다.
redux 브랜치에서 문제가 생겼다면 닫은 리덕스 브랜치를 다시 열지 말고,
hotfix/redux 브랜치를 만들어서 해결한다.

• 머지하면 브랜치를 다시 살리지 않는다. (클로즈)

그렇다면 작업이 마크업과 기능으로 나뉜다 했을때, 기능이 다 되어야 머지를 해야하는건가?
백엔드와 작업속도도 다르고, 다른 브랜치에서 만든 컴포넌트가 필요할 수도 있는데!

• 기능과 마크업을 각자 따로 나누어서 본다.
• 적은 브랜치를 갖는 게 좋다. 꼬일 가능성이 농후함

나는 지금 마크업을 하고 기능을 같이 만들고 있어서 혼돈이 많이 왔었다...
지금 브랜치가 상당히 많이 있고 꼬여있는 상태인데... 일단 만들어놓은 브랜치들 정리가 좀 필요할 것 같음!

2. 재사용 가능한 컴포넌트 만들기(+ 레이아웃)

나름 재사용 가능한 atom 요소를 만들어서 사용할 수 있도록 한 상태.
디자인상으로는 이정도만 있으면 충분하다 생각했는데, 막상 개발에 착수하다보니 확장성이 필요해 보였다.
다른 팀원한테서 버튼 크기나 폰트사이즈를 조절할 수 있으면 좋겠다는 피드백을 받은것.

import해서 styled(Button) 이런식으로 해서 오버라이딩이 가능할거라 생각했는데 안됨...
그렇다면 필요할때마나 Button.js 파일을 수정해서 새로운 디자인요소를 추가해야하는건가?
아님 커스터마이징할수있는 다른 방법이 있는 건가?
찾아보기로는 &&을 사용해서 하면 css 우선순위가 높아져서 디자인이 먹는다던데 해봐도 안되더라.

import styled, { css } from 'styled-components';

const SIZES = {
  circle: css`
    --button-padding: 10px;
    --button-radius: 50%;
    --button-width: 38px;
    --button-height: 38.39px;
  `,
  long: css`
    --button-padding: 10px 16px;
    --button-radius: 30px;
  `,
};

const FONTSIZES = {
  little: css`
    --button-font-size: 11px;
  `,
  middle: css`
    --button-font-size: 14px;
  `,
  large: css`
    --button-font-size: 18px;
  `,
};

const Btn = styled.button`
  ${props => props.sizeStyle}
  ${props => props.fontSizeStyle}

  padding: var(--button-padding);
  border-radius: var(--button-radius, 8px);
  background-color: inherit;
  box-shadow: 2px 2px 5px rgba(22, 27, 29, 0.25), -2px -2px 5px #faf8ff;
  width: var(--button-width);
  height: var(--button-height);
  border: none;
  margin-right: 10px;
  font-size: var(--button-font-size);

  &:active,
  &:hover,
  &:focus {
    box-shadow: inset 2px 2px 5px rgba(22, 27, 29, 0.25),
      inset -2px -2px 5px #faf8ff;
  }
`;

function Button({ size, fontsize, children, onClick }) {
  const sizeStyle = SIZES[size];
  const fontSizeStyle = FONTSIZES[fontsize];

  return (
    <Btn sizeStyle={sizeStyle} fontSizeStyle={fontSizeStyle} onClick={onClick}>
      {children}
    </Btn>
  );
}

export default Button;

일단 잘했다고 칭찬받았다. 실무에서 이렇게 한다고 하심!
보통 디자이너가 따로 있기도 하고 우리 회사에서는 버튼은 무조건 이렇게 생겼어,
이런식으로 디자인을 픽스하기 때문에 확장성이 중요하지 않은 것 같다.

만일 스타일을 추가하고싶다면 width, height을 추가하기보다

• 넓은 범위로 style이라는 프롭스를 준다.

function Button({ size, fontsize, children, onClick, style }) {

  return (
    <Btn sizeStyle={sizeStyle} fontSizeStyle={fontSizeStyle} onClick={onClick} style={style}>
      {children}
    </Btn>
  );
}

사용할때는

<Button style={{width:30}} size={sm}/>

이런식으로 인라인 스타일을 주는 듯!

그리고 재사용을 많이 하는 레이아웃 스타일을 따로 빼서 관리하는지도 궁금했는데,
내가 빼놓은 레이아웃은 빼놓는 게 좋아보인다고 함. 두번정도 쓰는걸로는 어림도 없지만
세번 이상 반복적으로 사용한다면 빼는 게 좋을 것 같다고 하셨다!
대신 이런건 팀원과 얘기를 한 후 진행을 해야한다고. 왜냐면 그래야 갖다쓰니까...

모달 컴포넌트 보이기/숨기기

우리가 개발중인 서비스는 페이지가 바뀌기보다 모달을 켜고 닫는 형식이라
레이아웃을 어떻게 잡을지, 생각한 애니메이션이 있는데 어떤 방식으로 구현할지가 고민이다.
일단 메인 페이지에는 메인 컴포넌트가 하나 떠있다.
그리고 모달을 키면 메인 컴포넌트가 옆으로 밀리면서 두개의 컴포넌트가 화면 한가운데 자리잡아야한다.

• 여러개의 모달을 관리하려면 모달의 상태를 중앙에서 관리해주는 게 좋을 것 같다고 하심(리덕스)

화면에 동시에 띄울 수 있는 모달은 최대 두개이며, 모달위치는 고정되어있다.

• 해당 모달의 id값으로 관리를 하고 만일 새로운 모달이 생성되는 시점에 중앙상태관리에서 현재 오픈상태인 모달의 id값을 확인하고 해당 모달의 애니메이션을 주어 이동시키는 방법을 쓰는 것을 추천하셨다.

구글로그인 OAuth 2.0

로그인부분을 처음부터 시작했지만 CORS 에러등 여러 에러가 난무해서 더 진행되지 못하는 상황이다.

어제 백엔드 팀원에게 들은 얘기로는 멘토님이 구글로그인은 백에서 할게 없고 프론트에서 다 해서 보내면 된다고 하셨다는데 프론트 멘토님은 얘기가 또 다르다.
안그래도 나랑 백엔드분이랑 그럼 프론트에서 토큰을 받고 찐인지 어떻게 알죠? 하면서 어리둥절 했었는뎈ㅋㅋㅋ
훔 내가 백엔드 멘토님 얘기를 직접 들은건 아니라서... 멘토님들 모아놓고 다같이 회의하고싶네....

• 일단 로그인 버튼을 눌렀을때 구글에서 토큰을 보내주는데,
  프론트에서 토큰을 관리하거나 검증할 필요가 없다.
  구글에서 무조건 되는놈만 보내기 때문.
  프론트에서는 구글에서 받은 토큰을 바로 서버로 보내면 됨.
  그럼 백에서 구글로 토큰을 보내서 비교하고 기존에 없는 유저라면 db에 저장하게 된다.

• jwt 토큰은 디폴트시간이 있으며 서버와 통신하면 유효시간이 늘어난다.
  그렇기 때문에 따로 특별한 이유가 있는 게 아니라면 굳이 유효기간을 늘리지 않는다.

그외

• CRA한 이유에 대해서 물어보셨다.
  이유 딱히 없다. 코드스테이츠에서 웬만하면 CRA하라해서 하라는대로 했음.
  근데 CRA로 했을때 빠르다는 장점이 있지만 또 단점도 많이 있기 때문에 공부해보면 좋을 것 같다고 하심!

• saga나 thunk 쓸거냐고 물어보심
  지금 딱히 안쓰고있긴한데.... 얘기 들어보니까 쓰는 게 좋을거같다는 생각이 든다.
  일단 진행하고 리팩토링하는게 좋을까...?
  사가나 썽크 안할거면 패치 전략을 세우는 게 좋다고 하셨다. 비동기처리때문에 쓰는거라.
  멘토님 회사에서는 Mobx쓰신다고.

• 리드미를 꾸밀 것을 추천하셨다.
  보통 회사에 포폴을 내면 코드를 보기보다 리드미만 보고 끝낸다고. 힝 몰랐네...

• 프로젝트의 목표를 어떤 기능을 구현했다, 로 하기보다 기획부터 배포까지 해봤다, 로 잡으라 하셨다.
  그런 의미에서 Action, CI/CD 강력추천하심!