회고

[SOLID 원칙] 프론트엔드의 SOLID 원칙과 과거 프로젝트에 대한 회고 첫 번째, 단일 책임 원칙

개형이 2024. 2. 22. 15:34

 

프론트엔드와 SOLID원칙에 대한 포스팅을 보고

회사에서 참여했던 프로젝트에 대해 많은 생각을 하게 되었다.

(물론 참여 프로젝트의 코드 품질이 좋지 않다는 생각)

 

따라서 포스팅의 글을 보며 참여했던 프로젝트에 대해 회상하며 반성해보고자 한다.

일종의 회고 시간.

 

참고한 포스팅은 아래와 같다. 좋은 포스팅 감사합니다.

https://fe-developers.kakaoent.com/2023/230330-frontend-solid/

 

 

 


 

 

 

❗️시작에 앞서 SOLID 원칙은 다음과 같다.

  • SRP : Single Responsibility Principle (단일 책임 원칙)
  • OCP : Open/Closed Principle (개방 폐쇄 원칙)
  • LSP : Liskov Substitution Principle (리스코브 치환 원칙)
  • ISP : Interface Segregation Principle (인터페이스 분리 원칙)
  • DIP : Dependency Inversion Principle (의존성 역전 원칙)

 

프론트엔드(React)뿐만 아니라 소프트웨어 설계에 전반적으로 적용되는 원칙이다.

 

아, 물론 SOLID 원칙에 대해 몰랐던 것은 아니다. 🤔

프로젝트에 참여하면서도 SOLID 원칙에 대해 한 번씩은 생각하며 코드 작성을 했고 코드 리뷰도 했었다. (순수 함수 타령을 하며...)

 

다만 참고한 포스팅은 단순히 코드 레벨에 대한 사항은 아니였는데,

이 부분에 대해 회고해보고자 한다.

 

 


 

 

 

1. 단일 책임 원칙 (SOLID의 S) (Single Responsibility Principle)

 

단일 책임 원칙은 아래와 같다.

"하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다."

 

사실 단일 책임 원칙이 하나의 모듈,
리액트로 보면 하나의 컴포넌트라고 생각할 수 있겠다.

 

이전에는 하나의 컴포넌트는 하나의 기능만 해야 한다라고 꽉 막힌 생각을 했던 것 같다.

(클린 코드 책에도 그렇게 적혀있긴 하지만 SOLID는 아키텍처적인 관점에서 바라봐야 한다.)

 

하지만 포스팅에서는 기능보단 '책임'에 집중하라고 되어 있다.

 

컴포넌트를 하나의 기능만 생각하며 잘게 쪼개는 방식보단

기획의 요구사항으로 나온 책임 단위로 설계해야 한다는 것이다.

 

이는 무슨 말일까?

기획 문서로부터 (포스팅에서는 정보구조도 문서를 활용한다고 함) 단일한 책임을 가지는 영역을 찾아

이를 컴포넌트로 만들어야 한다는 것이다.

컴포넌트 네이밍도 기획에서 정한 사항과 동일하게 해서 추후에도 커뮤니케이션 미스가 없게 해야 한다는 것이다.

 

 

🔬 내가 참여했던 프로젝트에서는 기획 문서가 이렇게 넘어왔다.

- 기획에 대한 히스토리, 계기, 상세 정보에 대한 노션 정리 문서

- 피그마에 UI를 그려주고 각 UI에 라벨링을 한 뒤 해당 라벨링에 대한 설명이 설명란에 기재되어 있음

 

아쉽게도 정보구조도와 같은 기획 문서는 따로 존재하지 않았다.

하지만 생각해 보니 피그마 UI에 각 라벨링에 대한 설명이 나름 정보구조도와 같은 역할을 한다고도 생각이 들었다.

 

여하튼 개발팀은 개발을 진행할 때 임의로 컴포넌트 재사용성을 고려하여 설계했고

네이밍도 임의로 정했었다. (임의로 정하다 보니 백엔드와도 네이밍이 안 맞는 경우가 간혹 있었다.)

 

🔭 이 부분들에 있어서 이렇게 했으면 어땠을까?

=> 피그마에 제시된 UI 라벨링을 기준으로 구조화, 이때 네이밍은 모두 기획에서 사용한 걸 그대로 가져간다.

=> 구조화에 있어서는 백엔드팀과 같이 논의하여 API 스펙과 컴포넌트 설계가 매칭이 잘 되도록 함.

 

예를 들어 한 영역에 상세 정보, 더 보기 버튼, 정보 복사하기 버튼이 있다면

피그마 문서에는 라벨링이 상세 정보, 더보기 버튼, 정보 복사하기 버튼에 하나씩 있었을 것이고

이를 기준으로 컴포넌트를 설계하는 것이다.

그리고 해당 기준을 백엔드와 미리 논의하여 스펙을 맞춘 이후 개발을 시작하는 것이다.

 

😇 나는 SOLID를 생각할 때 커뮤니케이션과 협업과는 전혀 관련이 없다고 생각했다.

하지만 앞서 말한 대로 개발을 진행하면

 

1) 기획이 변경되거나 추가되어도 책임에 따른 변경이 가능해짐

2) 백엔드와 간극이 줄어 쉽게 대응이 가능

 

위와 같은 이점을 챙길 수 있을 것 같다는 생각이 들었다.

 

 

 

🏙️ 디자인과 책임은?

 

디자인과 프론트엔드의 SOLID는 어떻게 챙길 수 있을까?

 

이 지점에 대해서는 명확히 알고 있었다.

포스팅에 언급한 방법을 적용하여 프로젝트에 참여한 경험이 있고,

그렇지 않은 프로젝트를 참여한 경험도 있다.

 

나는 회사에서 크게 두 가지의 프로젝트에 참여했다.

부르기 쉽게 A와 B라고 설명하겠다.

 

A 프로젝트는 출시가 꽤 오래전에 되었던 프로젝트였고 (필자는 신기능 추가 및 유지 보수 역할로 투입)

B 프로젝트는 초기 MVP부터 담당하여 출시까지 진행한 프로젝트였다.

 

A 프로젝트는 코드 품질을 생각할 겨를도 없이 빠르게 구축되었던 흔적이 아직도 많이 남아있었다. (레거시가 많다는 뜻)

B 프로젝트도 빠르게 구축되긴 했지만 출시 이후 디자인 시스템 전면 개편까지 모두 참여했다.

 

🔬 여기서 디자인 시스템 구축은 ⁉️

1) 피그마로 각 UI 컴포넌트에 대한 디자인 명세를 받음

=> UI 컴포넌트는 Typography를 시작으로 버튼, 인풋 필드, 체크박스 등과 같이 화면을 이루는 모든 컴포넌트.

2) 각 UI 컴포넌트에 디자인이 적용된 디자인 컴포넌트를 만듦

=> 해당 컴포넌트를 사용하여 화면 전체를 구성한다. (아토믹 디자인 시스템)

 

위와 같은 방식으로 진행했었다.

 

디자인 시스템이 있고 없고를 모두 체험해본 입장에서 디자인 시스템을 구축했을 때 다음과 같은 장점을 얻을 수 있었다.

- 디자인 요구사항이 변경될 경우 디자인팀에서 디자인 시스템에 대한 피그마 변경건을 제시하면 해당 디자인 컴포넌트만 변경하면 되는점.

- 같은 컴포넌트일 때 화면별로 상이한 디자인이 나올 일이 없다.

- 설령 테마가 변경된다고 해도 각 디자인 컴포넌트만 수정하면 전체적으로 변경이 완료된다.

 

🔭 따라서 디자인 책임을 디자인 컴포넌트에 맡기는 설계 관점에서도 디자인 시스템 구축은 매우 필요하다는 사실을 알게 되었다!

(물론 디자인팀에서 각 컴포넌트에 대한 디자인 시스템을 구축하여 제시해야 하지만...)

 

 

 


 

 

 

 

원래는 한 포스팅에 SOLID 5개의 원칙에 대한 회고를 모두 작성해보려고 했는데,

S 만 했는데도 길어진 것 같아서

다음 포스팅에 이어서 진행해보려고 한다.