더 좋은 개발 체험~ Atomic 디자인의 구성 요소 디자인~

React Advent Calendar 2019의 6일차 담당@takashima_katsu.

입문

약 4개월 전에 나는 React가 쓴 프로젝트에 참가했다.
이 프로젝트는 내가 계획에 참여한 반년 전에 개발된 것으로 기본적으로 서버 측을 위주로 하는 엔지니어 혼자서 프론트 데스크 부분을 책임진다.
구성 요소의 설계와 입도가 고르지 않기 때문에, "이미 어떤 물건을 다시 만들었다.""이미 존재하지만, 큰 구성 요소의 일부로서 긴밀하게 결합되어 있기 때문에 중복해서 사용할 수 없습니다."
이런 일은 자주 발생한다.
이 문장에서 중도에 그런 프로젝트에 참여한 나
조금만 더 그랬다면 좋았을 텐데.
개선할 계획의 개요를 기재하다.

개선하고 싶은 일

우선 개선점을 정리하는 것이다.
제가 계획에 참여한 상태에서.

Hooks 사용 안함

구성 요소 목록 없음

부품의 입도가 크다

이 삼중 조합의 DX(개발 체험)는 매우 나쁘다.

Hooks 사용 안 함

현재 React는 Hooks를 사용하지 않을 이유가 없습니다.
Hooks는 사용하지 않았지만 React16.8以上 물건을 사용했기 때문에 사용하고 싶으면 사용할 수 있습니다.
Redux와 최근react-router 등 주변 모듈도 Hooks를 추가했다.

훅스의 매력.

내가 느끼는 훅스의 매력은 간단하다.
React의 장점은 간단하지만 Hooks의 등장으로 이 단순성이 더욱 높아졌다고 생각합니다.
코드량도 단순히 줄었지만 생명주기 의존이 사라지는 경우도 많다.
이것은 모듈 디자인의 단순성과 사용자 정의 후크 보기에 의존하지 않고 모듈화 논리에 도움이 된다.
(나는 이것도 대상을 대상으로 함수형 언어를 도입했기 때문이라고 생각한다)
React와 Hooks를 잘 모르는 분들은 외관 부분과 논리를 각각 유연하게 사용하기 쉬워졌다고 생각하세요.
큰 개발을 진행할수록 외관 부분이든 논리든'같은 설치는 다른 곳에서도 했다'는 경우가 많다.
나는 그 문제를 간단하게 해결할 수 있다.
소형 미용
유닉스의 생각.에 쓴 것으로'작고 간단하게 유지하자'는 생각이 있다.
이것은 전체 소프트웨어 개발이라고 할 수 있다.
나는 단편적인 것이 아니라 긴밀하게 결합하고 희소하게 결합하며 미세하게 서비스하는 것도 여기라고 생각한다.
프론트 데스크에서 그걸 구현하고 싶은 도구 중 하나예요. 훅스도 있어요?

구성 요소 목록 없음

개발이 진행됨에 따라 구성 요소는 끊임없이 증가할 것이다.적당한 입도로 부품을 만들었다고 해서 참여한 사람도 파악하기 어렵고 이미 개발한 사람도 완전히 파악하기 어렵다.
그리고 구성 요소 목록을 만드는 것도 구성 요소의 입도를 고려하는 데 도움이 된다.
Storybook.
구성 요소 목록으로 사용할 수 있을 뿐만 아니라 아직 사용하지 않은 Snapshotテスト 등도 진행할 수 있다는 것도 장점이다.
(전혀 익숙하게 사용할 수 없어서 열심히 하고 싶은데...)

구성 요소의 입도가 크다

뒤의 상세한 설명에서 우리는 Atomic Design이라는 디자인 프레임워크를 채택하여 그것에 따라 구성 요소의 입도를 고려할 것이다.
내가 계획에 참여했을 때 이미 많은 것들이 Atomic Design이 말한 TemplatesOrganisms층 수준의 입도였기 때문에 이곳의 DX 향상을 의식하는 것만으로도 매우 크다.
전자 2개는 "Hooks를 사용하고 Storybook도 가져왔습니다"라고만 썼기 때문에 그보다 구성 요소 디자인에 대한 내용을 적겠습니다.
(여기는 아직 정답을 모르고 실험을 거듭합니다. 여러분이 댓글로 어떤 구성 요소 디자인과 디렉터리 구성인지 알려주시면 기쁩니다.)

능동 설계를 위한 구성 요소 설계

어셈블리의 입도를 결정할 때 세트 데이텀을 고려합니다.
다만 재활용성을 고려해 제작하면 엔지니어별로 분산되기 때문에 명문화할 필요가 있다고 생각합니다.
내가 조사해 보니 많은 사람들이 Atomic Design에 따라 설계한 것을 발견하였다.
"Atomic Design이 뭐예요?"이 보도에 관해서는 쓰지 않는다.
2013년에 발표된 것이기 때문에 이미 많은 보도가 있었다. 내가 조사에서 본 것은 국내 보도는 대부분 2~3년 전의 것들이기 때문에 내가 아는 것은 단지 늦은 것이다. 프론트 엔지니어와 디자이너 근처에서 이미 많은 이야기를 했고 가설은 당연한 지식이다.
Atomic Design은 엄격하지 않습니다.
디자인 프레임워크이기 때문에 팀에 따라 협조하는 것이 좋다고 생각합니다.
내 상황에서 Molecules층의 물건은 모두 Atoms로 정의된 것이 아니며 Templates의 개념도 없다.등장인물이 많아서 귀찮아요.

자기는 판면 디자인이 없어요.

배치는 상부에서 결정된다.
(Atoms 레이어의 레이아웃은 Molecules 레이어, Molecules 레이어의 레이아웃은 Organisms 레이어입니다...)
레이아웃 예시는width,margin,flex를 포함합니다.
레이아웃이 각 구성 요소에 의해 결정되면 재사용성이 떨어집니다.

최적화에 급급하지 않다

Atomic Design을 처음 알았을 때 나는 큰 병에 걸렸다.
무엇이든 구성 요소가 되고 싶은 병.
처음에 저는 엄격한 Atomic Design 규칙을 준수하여 최적화를 하고 싶었고 무엇이든지 그것을 구성 요소화하고 싶었습니다.
그 중에서 재활용이 필요 없는 구성 요소를 많이 만들었거나 지나치게 통용성을 가지기 때문에 코드량이 많아졌다.
Atomic Design은 중용성이 높고 시야가 좋은 구성 요소 디자인을 실현하기 위해 도입되었지만 중용할 수 없는 것들로 가득 차 있어 전체 디렉터리에서 볼 때 시야가 좋지 않다.

Rule of three

그 치료약은'Rule of three'입니다.
나는 무엇이든 구성 요소가 되고 싶은 병을 앓고 있는 나에게 이 규칙을 설정했다.
깨달은 것은 세 번 이상 나타나는 것만 구성화한다는 것이다.
최적화를 목표로 공전하는 나에게 특효약이다.

디렉토리 구성

디렉터리 설정은 이렇습니다.

Next.js도 이렇게 사용하고 있습니다.

오늘 이후로

이 말을 하면 무서운 사람에게 욕을 먹을 수도 있지만, 나는 시험을 쓰지 않았다.
'기분 있어요'라고 쓰고 싶어서 많이 봤는데 한마디로 시험이 너무 많죠?
솔직히 나도 테스트의 필요성을 잘 몰랐지만 최근 규격 변경으로 이와 관련된 다른 곳은 움직이지 않았다.
그리고 저는 발표 전의 새로운 개발만 해봤지만 앞으로 좋은 일만 하고 서비스로 키워야 한다는 생각에 생각을 바꿨습니다.
자, 파이팅!