우아한테크코스 프론트 : Lv.3 댓글 모듈 다라쓰 인사이트

1. 댓글 모듈 iframe 개발기

댓글 모듈 iframe 개발기

 

2. React에서 contentEditable 사용하기

React에서 contentEditable 사용하기

 

 

3. git flow

 여러 개발자와의 협업에서 깃 브랜치 전략을 필수이다. 커밋과 브랜치를 컨벤션 없이 개개인의 스타일로 작성하게 되면 나중에 무엇이 어떤 순서로 진행됐는지 알기가 너무 어렵다. 또한, 배포 브랜치와 개발 브랜치를 분리해야 이슈가 터졌을 때도 빠르게 대응할 수 있다.

 

 우리 팀은 깃 브랜치 전략으로 git flow를 선택했다.

master 브랜치

• 바로 배포 가능한 상태여야 한다.
• 에러가 없는 상태여야 한다.
• 삭제하지 않는다.

release 브랜치

• 전체 코드를 통합하기 위한 브랜치
• QA 진행
• 베타 버전
• (2021-07-06 추가 사항) release 브랜치는 배포 직전에만 백엔드와 프론트엔드 디렉토리를 합쳐서 오류가 나지 않는지 확인하는 용도로 사용하고, 문제가 없다면 삭제하는 방향이 긍정적으로 보임. 이 release 브랜치가 매번 유지된다면 merge 하는데 꽤 고통 받을 수 있음.

develop/fe, develop/be

• 개발자들의 통합 브랜치
• 주의) Merge할 때 issue 번호 끝에 남기기
  • ex) feat: 로그인 기능 (#2)

feature/{fe or be}/{개발 기능}/{이슈번호}

• 개인이 기능 단위로 개발하기 위한 브랜치
• ex) feature/be/login_in_naver/1, feature/fe/signup_error_fix/2

 우리 팀 브랜치 전략에서 주목할만한 부분은 develop을 fe와 be로 구분지었다는 것이다. fe와 be는 사용하는 언어와 환경이 모두 다르기 때문에 각 파트에서의 코드 변경이 서로 영향을 주지 않는다. 때문에 develop 브랜치를 fe와 be로 분리하면 fe에서 작업을 하다가 be에서 새로운 커밋을 쌓았다고 해서 pull을 받을 필요가 없어진다. 또한, 각 파트 별로 커밋 로그를 확인하기가 더 쉬워지고 리셋을 하거나 포스 푸쉬를 하더라도 사이드 이펙트가 줄어든다는 장점이 있다. 물론, 깃 사용에 익숙하다면 이러한 분리가 무의미하게 느껴질 수도 있지만 팀원 모두가 대규모 협업이 처음이라 이런 식의 분리가 우리에게는 꽤나 효율적이었다고 생각한다.

 

커밋 메세지 형태

• feat: 기능 추가
• docs: 문서 관련
• refactor: 리팩토링
• chore: 의존성 추가, 환경 설정, 빌드 관련
• style: 코드 스타일 변경 (띄어쓰기, 개행 등)
• fix: 버그 수정
• test: 테스트 코드 관련

 

 

4. 시멘틱 버저닝(git tag & github release)

 배포 이후에도 코드는 계속해서 수정된다. 배포 당시에는 발견하지 못했지만, 이후에 잘못된 동작을 하거나 예외적인 상황에 대한 에러 처리가 빠진 것을 뒤늦게 확인할 수가 있다. 또한 기능이 추가되거나 변경이 요구될 때가 있다. 이러한 때에는 코드를 수정해야 한다. 코드를 수정했다면 개발자 또는 사용자가 이를 확인하고 구별할 수 있어야 한다. 코드에서 이러한 차이를 구별할 수 있게 해주는 것이 바로 버전이다. 버전은 프로그램을 수정하거나 개선할 때마다 코드를 구분하려고 부여된 식별자를 의미하며 보통 숫자를 사용한다.

 

 시멘틱 버저닝은 버전 번호를 어떻게 정하고 올려야 하는지를 명시하는 규칙과 요구사항을 의미한다. 

 

 버전은 X.Y.Z를 따른다.

• 메이저 업데이트(X): 하위 호환성을 보장하지 않는 변경
• 마이너 업데이트(Y): 하위 버전에 대해서도 호환성을 보장하는 범위의 변경
• 패치 업데이트(Z): API에 영향이 없는 버그 수정

 깃에서는 코드 배포를 관리를 돕는 태그 기능을 제공한다. 태그는 특정 커밋의 해시 값을 가리키는 꼬리표를 의미한다.

다음과 같은 명령어로 현재 HEAD가 가리키는 커밋을 기준으로 태그를 생성할 수 있다.

git tag -a 1.0.0 // 태그 추가

 

 깃헙에서는 태그를 공유할 수 있는 기능을 제공한다. 깃헙의 Releases를 확인하면 해당 프로젝트의 태그와 버전을 확인할 수 있다.

git push origin 태그이름

 

github Releases

 

 Node.js의 Releases를 참고하여 Releases를 만들었다.

 

 

 

5. 다른 영역이 클릭 됐을 때 드롭다운 닫히게 만들기

const [isShowOptionBox, setShowOptionBox] = useState(false);
const ref = useRef(false);
ref.current = isShowOptionBox;

const onShowOptionBox = (event: MouseEvent) => {
  event.stopPropagation();
  setShowOptionBox(state => !state);
};

const onHideOptionBox = () => {
  if (ref.current) setShowOptionBox(false);
};

useEffect(() => {
  window.addEventListener("click", onHideOptionBox);
  return () => {
    window.removeEventListener("click", onHideOptionBox);
  };
}, []);

 다른 영역이 클릭됐는지는 특정 영역만 렌더링 하는 컴포넌트에서 알 방법이 없다. 따라서 window에 클릭 이벤트를 달아주어야 한다. 이 때, 특정 상태값을 이벤트 핸들러가 참조하게 하고 싶다면 ref를 사용하여 객체로 관리해주면 편하다. (isShowOptionBox를 객체로 해도 된다) 그렇다면 왜 객체로 관리해야하는 것일까? 만약 이벤트 핸들러에 객체를 사용하지 않고 boolean 타입을 사용하면 isShowOptionBox를 출력하면 항상 false가 뜨게 된다. 이는 isShowOptionBox 가 원시 값이기 때문에 발생하는 문제이다. setShowOptionBox에 의해 isShowOptionBox가 변경된다면 isShowOptionBox는 값이기에 다른 메모리 주소에 값이 저장되고 식별자는 변경된 메모리 주소를 가리킨다. 이벤트 핸들러는 최초에 함수가 등록되는 시점에서의 isShowOptionBox 식별자가 가리키는 메모리 주소를 가리키고 이를 유지한다(함수 스코프). 이 때문에 isShowOptionBox의 값이 변경되더라도 계속해서 false만 가리키는 것이다. 따라서 가장 최신 값을 유지하고 싶다면 객체를 이용하여 이벤트 핸들러가 참조값을 가리키도록 바꾸어야한다.

 

 

6. 모바일 마우스 호버 인터랙션 제거

@media (hover: hover) and (pointer: fine) {
  &:hover {
    color: ${PALETTE.WHITE};
    background-color: ${PALETTE.RED_800};
  }
} // 호버를 적용할 요소에 미디어 쿼리를 추가한다.

 모바일 터치는 터치할 때마다 마우스의 포인터가 이동하는 것으로 이해하면 쉽다. 따라서 터치가 일어났을 때 CSS의 호버가 동작한다. 하지만 터치가 끝나고 다른 곳을 터치하지 않으면 포인터의 위치는 변화가 없으므로 계속해서 호버된 채로 남아있게 된다. 때문에 모바일에서는 호버를 지우는 것이 필요할 수 있다. 우리 서비스의 경우 좋아요 상태에 따라 호버 색상과 기본 색상이 변경된다.

 

좋아요 없을 시

• 기본 색상: 검은색
• 호버 색상: 파란색

좋아요 있을 시

• 기본 색상: 파란색
• 호버 색상: 검은색

 이러한 인터랙션은 데스크탑에서는 의도한대로 잘 나오지만 모바일에서는 그렇지 않다. 모바일은 앞서 말한 터치 문제가 있기 때문에 좋아요 없을 시 클릭을 하면 좋아요가 있는 상태로 변경된다. 그리고 마우스 포인터는 좋아요 버튼 위에 있기 때문에 최초에 좋아요가 없는 것 상태와 동일한 색상이 렌더링 되게 된다. 이러한 문제를 해결하려면 PC에만 호버 스타일을 적용하면 된다.

 

7. CI/CD

 이번 협력 미션에서 처음으로 말로만 듣던 CI/CD를 적용해 보았다. 백엔드 파트는 이미 젠킨스와 Github Action을 이용하여 CI/CD를 적용하고 있었다. 프론트는 백엔드 팀원인 제이온의 도움을 받아 Github Action을 사용하여 CI/CD를 도입해보았다. 

 

 Github Action을 이용하여 특정 브랜치에 PR이 올라오거나 머지 혹은 푸쉬가 이루어졌을 때 자동으로 테스트와 배포가 진행되도록 했다. 이를 통해 리팩토링이나 기능 추가로 발생하는 오류들을 사전에 발견할 수 있었다. 또한, 매번 배포가 이뤄저야하는 상황마다 빌드를 하고 파일을 직접 S3에 올리는 수고를 피할 수 있어 좋았다. CI/CD는 개발 효율을 극대화시켜주는 프로세스라고 느꼈다. 주기적인 배포가 필요한 프로젝트를 하는 상황이라면 무조건 도입해야겠다. 젠킨스와 Github Action도 공부해봐야겠다.

 

8. Sentry 에러 모니터링

 프론트 단에서 발생하는 에러는 대부분의 경우 서버가 아닌 클라인트 사이드에서 발생하기 때문에 개발자가 무슨 에러가 어디에서 일어났는지 파악하기가 어렵다. 때문에 에러 모니터링 서비스인 센트리를 도입하여 배포 환경에서 발생하는 에러를 추적하고 관리하도록 하였디.

 

 

 위의 사진처럼 센트리를 이용하면 해당 에러가 어떤 컴포넌트에서 발생했는지 그 위치와 에러의 정보를 파악할 수 있다. 하지만 source map처럼 코드의 정확한 위치가 아닌 빌드된 코드의 위치를 나타내고 있다. 이는 센트리에서 제공하는 에러 바운더리를 사용했기 때문으로 추측된다. 여유가 된다면 직접 에러바운더리에서 센트리에 에러 로그를 보내도록 커스텀 해봐야겠다.