Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[박승훈] 챕터 2: 패턴성 검증, 프로토 패턴 그리고 세 가지 법칙 #13

Merged
merged 1 commit into from
Oct 18, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions 챕터_2/박승훈.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
## 들어가며

> 디자인 패턴은 개나소나 디자인 패턴이 될 수 있을까?

아니다. 새로운 패턴은 제안되는 순간부터 널리 채택되기까지 커뮤니티와 개발자의 여러 검증을 거쳐야 한다.


### 용어 설명

- 프로토 패턴(proto-pattern) : 아직 '패턴성' 검증을 모두 통과하지 않은 미숙한 패턴
- 패틀릿(patlet) : 프로토 패턴에 간단한 설명을 덧붙여 공개하는 경우, 이러한 설명이나 코드 조각


### 좋은 패턴의 특징

- **특정 문제를 해결할 수 있어야 한다.**
- **반복되는 현상, 또는 문제에서 지속적으로 사용되어야 한다.**
- 설명대로 잘 동작해야 한다.


### 반복성을 입증하는 방법

- 목적 적합성: 어떻게 좋은 패턴이라고 판단하는지
- 유용성: 왜 좋은 패턴인지
- 적용 가능성: 넓은 적용 범위를 가지고 있는지

## 마치며

> 모든 프로토 패턴이 패턴으로써 인정되는 것은 아니다!

## 총평

프론트엔드 진영에서 꽤나 핫했던 **FSD 아키텍처**([링크](https://feature-sliced.design/))가 팀에서 신규 프로젝트 구성 때 발의가 되어서 도입해본 적이 있어요. 그리고 꽤 오랜 시간 러닝커브와 타협의 시간을 거쳐 피를 많이 보고 모두 걷어냈어요. FSD 아키텍처는 이름처럼 디자인 패턴보다 거시적인 아키텍처이지만, 좋은 패턴인지 판단하는 상황에서는 함께 적용해볼 수 있을 것 같아요.

FSD 아키텍처는 현재까지의 프론트엔드에서의 유지보수성에 대한 염증을 해결하기 위해 등장했어요. 2018년 베를린 React Day에서 언급되었으니 생소한 이름보다는 꽤 나이를 먹은 패턴이죠. 도메인/기능 중심(Feature-Sliced)이 컨셉이고, 어쩌면 실제로 좋은 패턴일 수 있어요. 하지만 저희 팀의 상황에서는 Public API로 인터페이스를 숨기는 것이나, layer를 다양하게 나누고 성격에 따라 분리하는 새로운 분류 방법이 실제 작업 환경에 적용하기에는 조금 거리가 있거나 효용에 비해 불필요한 개발 공수가 과하게 투입된다고 팀원 대부분이 느끼게 되었어요.

위에서 말하는 좋은 패턴의 특징에 대입해보면 **목적 적합성**은 잘 갖췄으나, 저희 상황에서는 **유용성**에 대해 설득이 안 되지 않았나 싶네요. **좋은 패턴의 특징들**에 대해 되돌아볼 수 있는 경험이 있어 기억에 많이 남는 것 같아요.
Loading