개요.
개발자로써 [ GitHub만 있으면 그만 아니야? ] 라는 생각으로 살다가 어느날 문뜩
프론트엔드 개발자인데 정작 나를 위한 웹사이트는 하나도 없네?
생각을 하게 되었다.
비교적 옛날 유형어 자기 PR의 시대라는 말이 있는데 나를 알리기 위해서 어떤 것을 보여줄 수 있을까?
하다 못해 관심이 있는 SEO를 마음껏 고려하면서 홈페이지를 만든다면 괜찮지 않을까?
또 내가 배우며 공부한 기능, 기술을 회사에 100% 반영할 수 없는 것은 당연한 현실이다.
공부에서 끝나지 않고 자연스럽게 홈페이지에 적용한다면 그것도 재밋지 않을까? 라는 생각을 했다.
그 첫번째 시작이 개발 환경 구성이다.
히스토리.
현재 회사의 개발 환경은 내가 프로젝트를 진행하면서 경험한 불편함을 보안하면서 만들고 있다.
( 이것을 2년차 개발자인 내가 하는게 맞는지? 또 제대로 만들고 있는지에 대한 두려움이 항상 존재한다. )
처음에는 마냥 좋아보이는 Storyboard, jest 등등을 넣을 생각을 했는데 이러한 업데이트가
동료 개발자의 작업 속도를 오히려 늦출 수 있고 그들의 개발 환경 러닝 커브가 너무 좋지 않을까? 라는 생각을 하게
되었다.
테스트 커버리지가 높으면 당연히 좋지만 주니어로 구성된 현재 회사 환경에서는 작업을 하면서 테스트 코드를 같이
작업할 준비가 되어 있지 않았다.
나의 욕심과 현실을 잘 비교하면서 개발 환경을 만들다가 이번에는 나만을 위한 개발 환경을 구성해보려고 한다.
변경점.
실컷 이야기하긴 했지만 이번 개발 단계에서 테스트 코드를 작성할 필요가 있을까 고민을 하긴 한다.
어찌보면 포트폴리오 홈페이지를 만드는 것인데 포트폴리오에 당장은 복잡한 기능이 들어가는 것이 아닌 사용자가
나를 효율적으로 이해할 수 있는 것이 중요하기 때문이다.
그러므로 Jest 기각.
StoryBoard 역시 협업을 하는 것도 아니고 준비되어 있는 UI가 있는 것이 아닌 내가 UI와 기능을 동시에
개발하는 상태이기 때문에 굳이 필요할까? 싶은 생각이 있다.
그러므로 StoryBoard 기각.
ㅋㅋㅋㅋㅋ 마냥 좋아보이는 것들을 말한지 10분도 안되서 전부 추가하지 않겠다고 했는데 그럼 뭘 하는것인가?
생각이 들 수 있다. 우선 Atomic Design Pattern을 좀 더 본격적으로 사용해보려고 한다.
Atomic Design Pattern.
지금까진 Atom => Molecules => Organisms => Page 단계를 통해서 개발을 진행했다.
각 폴더의 의미는 동일하고 특이점으로 Template이 없다.
없는 이유는 그 당시에는 Template의 역할을 Page가 해도 충분하지 않을까? 라는 생각을 했다.
실제로 대부분의 상황에 Template은 딱히 필요하다고 느끼지 못했고 Page로도 충분했다.
// Page
<Box> <=== Atom
<ProductCategory /> <=== Organisms
<Box>
<Input /> <=== Atom
<Select /> <=== Molecules
</Box>
<ProductList /> <=== Organisms
</Box>
Page에 Organisms은 물론 Atom과 Molecules의 조합으로 화면을 구성했다.
진짜 특별한 문제는 없었는데, 간혹 서버 데이터를 받는 과정에서 Page를 구성하는 컴포넌트가 데이터가 반드시 존재
해야지 동작하는 코드들이 있을텐데 이부분을 Page에서 처리하는 과정에서 불편함을 느꼈다.
// Page
const {data, isLoading, ... } = useProductList();
const currentTitle = data?.title + ...;
const something = somethingFuc(data);
<Box> <=== Atom
<ProductCategory /> <=== Organisms
<Box>
<Input /> <=== Atom
<Select /> <=== Molecules
</Box>
<ProductList /> <=== Organisms
</Box>
데이터를 불러오고 처리하는 과정에서 currentTitle이나 something이 반드시 data가 존재해야지 돌아가는
코드라고 생각해보자
어떤어떤 방법으로 당연히 해결할 수 있겠지만 Template이 존재한다면 렌더링 부분을 Template에 넘겨주고
API 호출이 완료되면 Template에게 넘겨준다면 이런 작업을 할 필요가 없을 것이다.
내가 이야기하는 것은 불편함을 Template을 사용하면 줄일 수 있을 것 같은 부분이다.
다음으로 Atom의 스타일 요소이다.
Styled-components.
Atom 요소를 구성할 때 스타일을 따로 Styles 폴더에 각각 속성으로 만들어줬다. 그때의 룰은 [ 스타일 요소는
반드시 Atom에만 존재해야 한다. ] 가 룰이였다.
즉, Molecules, Organisms 등에서는 스타일을 사용할 수 없는 것이다. 그래서 Hover나 Active 같은 부분을
구현하기 위해서 이상한 스타일 속성구현, Hover라는 컴포넌트를 만들어서 JavaScript로 구현해야 했다.
CSS로 구현할 수 있는 요소를 규칙으로 인해서 JavaScript를 사용해야 한다는게 추후 개발이 진행되면서
너무 불편하다고 느꼈다.
그래서 Hover, Focus 같은 요소는 어디서든 사용할 수 있는게 어떨까 생각을 하고 있다.
또한 스타일을 주는 방식의 차이도 있는데 :
<Box
display= {{
type: "flex",
align: "center",
justifiy: "space-between"
}}
>
// ...
같은 방식으로 유사한 스타일을 묶어서 객체로 넘겨주는 방식을 사용했다.
분명 장점은 존재했는데, 각 스타일이 어떤 요소인지 알 수 있으므로 이해가 쉬울 것이고 사용하기도 편하게 느껴졌다.
하지만 객체로 넘기고 있으므로 자식 컴포넌트가 React.memo를 사용할 수 없다.
이것은 매우 치명적이라고 생각해서 현재 작업하고 있는 환경에서도 어떻게 개선을 하려고 한다.
이것을 다르게 사용하려고 하는데,
import { css } from "styled-components";
const size = css`
width: ${(props) => props.$width};
height: ${(props) => props.$height};
max-width: ${(props) => props.$maxWidth};
max-height: ${(props) => props.$maxHeight};
min-width: ${(props) => props.$minWidth};
min-height: ${(props) => props.$minHeight};
aspect-ratio: ${(props) => props.$aspectRatio};
object-fit: ${(props) => props.$objectFit};
`;
export default size;
이런식으로 묶어서 관리를 하는 것은 동일하지만 사용은 각각으로 하는 방식이다.
또 $을 사용하는 이유는 실제로 존재하는 속성과 중복이 발생할 수 있어서 구분을 위해서 이렇게 사용하고 있다.
이렇게하면 스타일을 위한 코드 라인은 증가하겠지만 성능 최적화와 비교했을 때는 중요도가 낮다고 생각했다.
이렇게 크게 2가지 Atomic Pattern과 Style-Components 변경했다.
더 많은 것을 변경해보고 싶지만 천천히 환경을 변경해가는 것도 중요하다고 생각되므로 이번 환경을
여기까지 업데이트 하려고 한다.