첫 협업프로젝트 회고 (2)

📚 What I Learned (2)

어떻게 보면 정말 기본적인 것들도 당시에는 몰랐기에.. 당시 느꼈던 점들을 한번 적어보겠습니다ㅎㅎ

1. CSS-in-JS 라이브러리 : styled-jsx

css-in-js 라이브러리로 대표적인 styled-components와 emotion이 있다. 프로젝트를 진행하면서 styled-jsx는 처음 접해봤다. styled-jsx의 장점과 사용에 대해서 잘 정리된 글이 있다.

일반 css를 작성하는 방법과 매우 유사하고, 간단한 스타일링에 있어서는 straightforward하게 볼 수 있다는 장점이 있어서 이번 프로젝트에 적용해본 것 같다.

//사용 예시
const Button = () => (
  <div>
    <button className="btn"> 버튼 </button>
     <style jsx>{`
        button {
          padding: 20px;
          background: #eee;
          color: #999
        }
     `}</style>
  </div>
)

2. npm install

전 편에서 혼자 몇시간 삽질했다는 것이 바로 이 부분이다.
팀원이 세팅한 프로젝트를 깃허브에서 clone 받아 내가 작업을 하는 방식이였는데, 처음에는 dependencies에 있는 모듈을 설치해줘야한다. 이때 중요한 점은! npm install은 프로젝트가 위치한 디렉토리, 즉 package.json 파일이 위치한 최상단 폴더에서 진행해줘야한다.
나는 당시에 프로젝트가 위치한 곳이 아닌 다른 파일에서 설치하여 몇시간 동안 고민했었다..ㅎ

3. Eslint와 Prettier

Eslint는 JavaScript의 스타일 가이드를 따르지 않거나 문제가 있는 안티 패턴들을 찾아주고 일관된 코드 스타일로 작성하도록 도와준다. 코딩 컨벤션 및 안티 패턴을 자동 검출한다는 점에서, 코딩할때 eslint사용은 최근에는 거의 필수이다.

Prettier는 정해진 규칙에 따라 자동으로 코드 스타일을 정리해 주는 코드 포멧터이다.

Eslint와 Prettier는 특히 혼자가 아닌, 여러 사람들과 협업할 때 코드의 일관성을 높여주기 위한 도구이다. 개발자 각자 설정해둔 규칙에 따라 어떤 팀원은 double quote를, 다른 팀원은 single quote를 사용하면 하나의 프로젝트이지만 코드의 일관성이 없으므로 이러한 점에서 eslint와 prettier를 사용하면 좋다.

4. 더미 데이터

보통 프로젝트를 할 때 프론트엔드는 크게 디자이너가 작업한 와이어프레임을 토대로 퍼블리싱 + 서버 개발자와 통신하여 데이터 주고받는 작업이 있다.
당시 우리는 뷰가 많거나 반응형으로 구현하는 것이 아니였기 때문에 퍼블리싱하는 것은 그렇게 오래걸리지 않았다. 그러면 서버로부터 API가 완성되지 않은 상황에서 프론트엔드는 뭘 할 수 있을까?

리드개발자님이 "서버가 나오기 전까지 더미데이터로 일단 작업해주세요." 라고 하셨다. 당시에는 더미데이터가 뭐지? 어떻게 미리 작업할 수 있지? 라는 궁금증이 있었다.

더미데이터는 서버와 본격적으로 데이터를 통해 통신하기 전에, 미리 넣어둔 일종의 예시 데이터이다. 당시 사용자로부터 시험지 입력정보를 받아와서 화면에 보여주는 과정에서, 우리는 아직 데이터를 받아오는 기능까지 구현할 수 없으므로 미리 examInfo라는 더미객체를 설정하여 화면에 뿌려주는 코드까지 작성해놓을 수 있다. 그러면 나중에 서버가 완성되었을 때 해당 부분을 비동기로 받아오는 코드로 변경하면 되므로 미리 이렇게 데이터가 어떤식으로 구성될지 더미데이터로 작업해두면 효율적인 것 같다.

5. 상태관리

프로젝트 규모가 커질수록 상태관리의 필요성이 증가한다.
이번 프로젝트에서 redux를 사용하여 상태관리를 했는데, react 자체도 처음이었는데 거기에 redux까지 접하다보니 머리가 너무 복잡했다. 간단하게 말하면,

컴포넌트간 props를 통해 데이터를 주고받을때 애플리케이션의 규모가 커질수록 상태 관리가 매우 복잡해지게 된다. 하지만 Redux를 이용하면 중앙에서 상태를 관리를 하는 store(저장소) 가 존재하고, 상태(state)의 변경 내용이 저장소를 통해 dispatch(변경 사항이 저장소에 갱신)하고, 그 내용을 참고하는 다른 컴포넌트들이 subscribe 하는 방식이다.

redux에 관한 내용 및 사용법은 공식문서에 자세하게 설명되어 있다.

그 중에서도 redux-thunk 또는 redux-saga 미들웨어를 사용하느냐에 따라 사용 방법도 조금씩 다르다.
우선 해당 프로젝트에서는 redux-thunk를 사용했다. 이 미들웨어를 사용하면 액션 객체가 아닌 함수를 디스패치 할 수 있다. 음..사실 아직은 잘 모르겠다. 조만간 제대로 공부하면서 따로 포스팅을 올릴 것이다.

6. 공통 스타일 속성 관리

해당 프로젝트에서 특히 #4893c4, #8ec2dc 등 파란색 계열의 색상들이 공통적으로 많이 사용되었다. 그런데 개발을 하면서 매번 저 컬러코드를 작성하는 것도, 개발자가 기억하는 것이 효율적이지 못하다는 생각이 들었다. 이번 프로젝트에서 이 부분을 따로 해결하지는 않았지만, 다른 프로젝트의 코드를 보니 css 컬러코드를 변수화하는 방법이 있었다.

:root {
  --theme-color: #eef2f6;
  --primary-color: #3c64b1;
}

이렇게 프로젝트의 주요 컬러는 css 파일에 네이밍하여 변수화한다면 해당 변수이름으로 보다 편리하게 스타일을 적용할 수 있다. 사용할 때는 color : var(--theme-color); 와 같이 적용하면 된다.

최근에는 CSS in JS 라이브러리로 styled-components를 사용해봤는데, 이때는 ThemeProvider를 사용하여 공통 속성을 관리하면 된다.

7. propTypes

자바스크립트는 유연한 특성 덕분에 코드를 작성하는 것 자체가 편할지언정, 프로젝트 규모가 커질수록 관리해야할 파일도 많아지고 이 때문에 예상치 못한 곳에서 에러가 발생하기도 한다. 이를 방지하기 위해 최근에는 Typescript를 많이 도입하는데, Javascript를 사용하기로 했다면 PropTypes를 함께 사용하는 것을 권장한다고 한다.

PropTypes는 부모로부터 전달받은 prop의 데이터 type을 검사한다. 자식 컴포넌트에서 명시한 데이터 타입과 부모로부터 넘겨받은 데이터의 타입이 일치하지 않으면 콘솔에 에러 경고문이 띄워진다.

실제로 이번 프로젝트에서, boolean값을 넘겨주는 과정에서 outline={true}라고 작성해야할 것을 outline="true"와 같이 string값으로 넘겨준 실수를 한 적이 있다.

더더욱 타입 명시의 중요성을 깨달은 것 같다.

8. 불필요한 console.log()는 지우자

구현을 완료하고 코드를 올릴 때 console.log()는 지우도록 하자. 보통 form을 구현하거나 할때 값이 제대로 입력되어 submit이 되는지 등을 확인하기 위해 작성했는데 최종적인 코드를 커밋할 때는 불필요한 코드가 되므로 지워주도록 하자.

9. 컴포넌트 재활용성

모달이나 버튼, TextField 같은 경우 프로젝트 내에서 공통적으로 사용되는 컴포넌트 중 하나이다. 사용되는 곳에 매번 반복적인 코드를 구현하고 있으면 얼마나 시간 낭비이며 비효율적일까..

그래서 컴포넌트의 재사용성을 높이고자 따로 컴포넌트로 구분하도록 한다.
예를 들어 버튼 안의 문구만 다르다면, 이를 props로 전달받아 사용하는 곳에 알맞게 적용하면 된다.

최근에는, 협업 시 storybook이라는 것을 많이 활용한다. 다음에 자세한 포스트로 다뤄볼 예정이다.

storybook은 UI 컴포넌트 개발 도구로서, 비즈니스 로직과 컨텍스트로부터 UI 컴포넌트를 독립적으로 분리하여 만들수 있도록 도와줍니다.
React를 위한 Storybook 사용법

10. 네이밍

개발자에게 있어서 네이밍은 언제나 고민의 과정이다..
이번에 나는 특히 여러 태그를 사용하면서 className을 어떻게 지정해야할까 고민한 적이 많다. 어떻게 서로 구별되면서, 각 태그를 설명할 수 있는 className을 지을까 궁금해서 찾아본 결과 BEM이라는 컨벤션이 있다.

BEM(Block Elements Modifier) : css naming convention 중 하나

• Block : 재사용 할 수있는 기능적으로 독립적인 페이지 구성 요소
• Element : 블록안에서 특정 기능을 담당하는 부분
  (block__element 형태와 같이, 더블 언더바를 사용하여 표현)
• Modifier : 블록이나 요소의 모양(color, size..), 상태(disabled, checked..)를 정의
  (block__element — modifier, block — modifier 형태와 같이 더블 하이픈 사용)

11. 공식문서가 선생님

모르는 것을 마주할 때 구글링을 많이 하고 여러 자료들을 통해서 해결하곤 한다. 물론 다양한 기술 블로그를 통해서도 궁금증을 해결할 수 있지만, 가장 좋은 참고자료는 바로 공식문서이다. 가장 정확하고 확실한 정보를 얻을 수 있으며, 사용 방법 또한 자세하게 설명되어 있다. 공식문서를 읽고 이해하는 습관을 키우는 것도 좋을 것 같다.

---

✨ 최종 회고..

• 여태껏 개발 공부를 잘못하고 있었다는 생각이 정말 크게 들었다. 심지어 반응형 레이아웃을 위해 사용하는 css의 flex 및 grid에 대해서도 이번에 처음 제대로 공부하고 적용해봤다. 그 동안 너무 체계없이 공부했던 것 같다. 뭐든 하나를 공부하더라도 "제대로" 아는 것이 중요한 것 같다. 그 과정에서 알게 된 것들을 기록하는 습관을 가지자.
  
  => '기억보다는 기록을' 이라는 말이 있다. 당시 프로젝트를 하면서 순간 순간 배우고 공부한 내용들이 있는데 당시에는 블로그를 활용한 기록을 하지 않았다. 아니 잘 몰랐다.
  기록 해놓지 않으면 내 기억은 그렇게 오래가지 못한다. 당시 얻은 새로운 지식은 꼭 추가적으로 더 공부해서 블로그에 기록하도록 하자. 훗날 큰 자산이 될 것이다.

• 다른 사람의 좋은 코드와 코딩 습관을 많이 보고, 많이 배우자. 이번에 다른 팀원의 코드와 구조를 보면서 "아 같은 기능을 짜더라도 이렇게 깔끔하게 구현할 수 있구나, 이렇게 코드를 분리하여 재사용성을 높일 수 있구나" 등을 뼈저리게 깨달은 것 같다. 좋은 습관들을 나만의 것으로 터득하고, 다음 프로젝트에서 한번 적용해보자. 점차 발전할 수 있을 것 같다.

• 역시 혼자만으로는 개발을 온전히 이해할 수 없다. 협업을 해보면서 github에서 여러번 충돌도 나고, 몇시간씩 헤매며 큰 좌절을 느끼기도 했었지만 아마 처음이라서 그랬던 것 같다. 처음부터 완벽한 사람은 없다. 그렇게 직접 여러 상황들을 경험해보니까 깃허브 사용에 조금씩 익숙해졌고, 이론으로 몇시간씩 읽어봤던 것보다 훨씬 잘 와닿았다.

아무 경험도 없이 부딪혀본 첫 프로젝트에서 정말 많이 실수하기도 했지만, 이를 통해서 많이 배웠고 내가 잘못 공부하고 있었던 것, 그리고 앞으로 어떻게 공부해야할지 방향을 잡을 수 있게 된 것 같다.