부트캠프를 마치고 3개월간 프론트-엔드 개발자로 일하면서 느낀점들

cyranocoding·2020년 3월 1일
13

my impression

목록 보기
3/3
post-thumbnail

간만에 포스팅인것 같다. 일을 시작하고 개인 블로그 따위는 저 멀리 내팽겨쳐놓고 원없이 개발만 한 것 같다. 짧으면 짧고 길면 긴 시간인데 이 시간동안 넥스트-리액트 프론트 엔드 개발을 하면서 가장 크게 느꼈던 점을 적으려고 한다. 본 내용은 지극히 개인적인 느낌이므로 다른 회사나 다른 개발환경에서는 공감이 안될 수 있다. 하지만 나름 새롭고 좋은 것은 무조건 적용하자는 회사의 개발 방침과 환경에서 느낀점이니 참고하길 바란다.

라이프사이클에 대한 정확한 이해와 리액트 훅스(Hooks)에 미리 익숙해질걸.

가상 돔(DOM)을 사용하는 리액트 특성상 라이프사이클에 대한 이해는 필수적이다. 나도 많이 이해하고 있다고 생각했으나... 처음 일로서 리액트를 접했을 때, 가장 많은 실수를 한 것이 바로 라이프사이클과 렌더링에 대한 것들이었다. 순서도 알고 어떻게 컴포넌트가 렌더링 되는지 아는데 아는 것과 실제 적용해보는 것은 다른 차원의 문제였다. 이론적인 이해와 더불어 많은 연습을 하고 이해를 했어야 했다.

정확한 것은 모르지만 클래스 컴포넌트로 일일이 라이프사이클을 지정하여 코딩을 했던 것이 점점 hooks로 넘어가는 추세라고 한다. 직접 코딩을 해보면 알게지만, 안 쓸 이유가 없을 정도로 간단한 메커니즘을 가지고 있기 때문에 이 또한 연습하고 가면 좋을 것 같다. 참고로 나는 지금 스토어 관리도 Context API를 사용한다. hooks와 잘 어울리는 것 같다. Redux로 개고생했던 기억이 새록새록....

실제로 부트캠프에서는 간단한 컴포넌트를 만들때만 functional component를 사용하였고 그 외에 스테이트를 관리하는 컴포넌트들은 class 형태를 사용하였다. 지옥같은 this binding을 생각한다면 지금은 참 편하다 ㅎㅎ

결론으로 말하자면 hooks는 꼭 써보자. 시간이 된다면 Context API도 써보는 것을 추천한다.

Styled-Components도 써보자

프론트엔드 개발은 결국 화면으로 보여줘야 한다. 그렇기 때문에 css도 신경 안 쓸 수 없다. 뒤 쪽을 코드를 아무리 바꿔보았자 css로 border 색깔 바꾸는 것만 못한다. 어플리케이션으로 평가 받기 때문이다.

그럼에도 불구하고 css는 여간 귀찮은 일이 아니다. 코드 베이스가 커지면 커질수록 개발팀 = className 작명소가 된다. 일정 규칙을 넣어 놓고 하긴하지만 각각 네이밍을 해주면서 분리하는 과정은 낭비라고 생각한다. 또한 공통으로 사용하는 변수들을 일일이 임포트해줘야 한다. 이 과정을 커버해주는 라이브러리가 Styled-Components라고 생각한다. 사용해보면 알겠지만 꽤나 강력한 기능에 놀랄 것이다.

장점을 모아 본다면,

  1. 공통으로 사용하는 style 변수들을 Provider 패턴으로 모든 콤포넌트에 내려줄 수 있다.(임포트 하지 않아도 됨)
  2. 리액트의 jsx 파트가 직관적으로 바뀐다. <div className = "banners-image-wrapper" /> =>Banners Component - <ImageWrapper />
  3. css를 Java script style로 코드 작성이 가능하다.
  4. props를 내려주어서 조건부 서식을 적용하기에 용이하다. <ImageWrapper big /> => 이렇게 작성할 수 있고 big 변수를 받아 big === true 일때 서실을 다르게 적용할 수 있다.

등등

부트캠프에서는 scss less와 같은 프리프로세서들을 사용했었는데 100%활용하지는 못했다. 실제로 일을 하면 다양한 케이스에서 사용할 수 있지만, 연습이라도 해보면 훨씬 개발이 편할 것이다.

다른 사람들의 코드를 잘 이해하도록 해보자

이건 내가 정말 안 했던 것이다. 그냥 기능 구현에 집중했고, 나 혼자 하는 것이 익숙했다. 하지만 회사에서는 모든 프로세스가 협업으로 이루어진다. 깃(Git)도 함께 사용하고 같은 코드를 함께 보고 다른 사람이 쓴 코드를 내가 수정해야 하는 경우가 있다. 아니 그 일이 대부분이다. 처음 한 두 달 간은 기본 레거시 코드를 이해하는데 모든 시간을 다 쓴 것 같다. 코드 작성자가 나름의 스킬, 철학(?)을 가지고 작성한 코드를 수정하거나 리팩토링 하는 작업을 해본 경험이 없어서 처음에 엄청 힘들었다. 그냥 내가 새로 만드는게 더 빠를듯? ㅎㅎ

하지만 이 과정은 전체 프로젝트를 완성하는데 필수적이며 항상 해야 하는 일이다. 여기에 적응하지 못하면 혼자서 개발하는 것을 추천하고 싶다. 다른 사람의 코드를 읽고 이해할 때, 그 플로우를 이해하는 것도 중요하지만 그 사람이 어떤 생각과 철학을 가지고 이 코드를 작성했는지 파악하는 것도 중요하다고 생각한다. 스타일과 철학을 해치지 않는 범위에서 수정하는 것이 중요하다고 생각하기 때문이다. 이 코드는 내 스타일로 다시 써버린다면 모든 코드를 리뷰해야 할 수도 있도 어떤 사이드 이펙트가 있을지 아무도 모르기 때문이다.

변수보다는 폴더구조로 표현하면 더 이해하기 쉬워진다.

개발자는 작명가이다. 수많은 변수들에게 이름을 부여하고 역할을 만들어줘야 하기 때문이다. 이 코드는 남들이 봤을 때 이해하기 쉽도록 하는 변수를 만드는 것도 하나의 능력이라고 생각한다.

다음을 예로 들어보자.

User Component에

고객 정보를 업데이트하는 함수 = updateClient

고객정보를 삭제하는 함수 = deleteClient

보통 이렇게 만들어놓고 컴포넌트에 넣어두었다.

그런데 User의 종류가 별로 없다면 컴포넌트를 구분하면 더 이해하 쉬워진다.

User
│   index.js
│
└───Client
│
└───Admin

위와 같은 방식으로 구분한다면 위에서 언급한 함수들은 Client Component 안에 

고객 정보를 업데이트하는 함수 = update

고객정보를 삭제하는 함수 = delete

위와 같이 변수를 설정해도 된다.

변수 하나 만으로 그 변수를 이해하기 보다는 structure와 함께 이해하도록 만들면 조금 더 간단하고 직관적으로 바뀌게 된다.

물론 이 것은 상황에 따라 매우 다르다. 무조건 컴포넌트를 나누는 것이 좋은 결과를 가져오지 않는다.

위의 내용은 일하면서 느낀 것들, 공부할 때 후회 했던 것들을 정리한 것이다. 부트캠프에서 공부하고 있다면 도움이 되었으면 한다. 그 외에도 추상화된 컴포넌트를 만들어보기, form 기능 확장해서 사용해보기 등등 실무적으로 필요했던 부분들은 많은데 이것은 일하면서 배우는 편이 더 좋을 것이다.

profile
개발자로 한걸음 한걸음 가고 있어요.

5개의 댓글

comment-user-thumbnail
2020년 3월 7일

부트캠프에서 리액트를 써보는 중인데 방향성에 대해서 생각하던 중 글을 읽고 어느정도 감을 잡은 것 같습니다. 좋은 글 감사합니다!

1개의 답글
comment-user-thumbnail
2020년 4월 1일

좋은 글 잘 읽었습니다!! 게임 디자인 너무 취향 저격이에요!

답글 달기
comment-user-thumbnail
2020년 4월 10일

그런데 User의 종류가 별로 없다면 컴포넌트를 구분하면 더 이해하 쉬워진다.
그런데 User의 종류가 별로 없다면 컴포넌트를 구분하면 더 이해하기 쉬워진다.

답글 달기
comment-user-thumbnail
2020년 4월 10일

저도 저 게임 해보고 싶어요... 재밌어 보이네요 ㅠㅠ

답글 달기