Design Patterns : 시간이 나에게 가르쳐 준 아키텍처

Source: Dev.to

소개

개발자라면 반드시 Gang of Four 책을 접했거나 디자인 패턴에 관한 시험을 공부했을 겁니다. 경력 초반에는 디자인 패턴이 마법 같은 “케이크 레시피”처럼 보이죠. 하지만 수년간 많은 시스템을 운영하면서 깨달은 것은, 진정한 시니어 역량은 이러한 패턴을 외우는 것이 아니라 언제 사용하면 안 되는지 아는 데 있다는 점입니다.

개발자로서 어느 정도 경험을 쌓아가며 느낀 점은, 디자인 패턴이 공통된 어휘 역할을 한다는 것입니다. 패턴은 코드를 “예쁘게” 만들거나 복잡하게 만들기 위한 것이 아니라, 코드를 지속 가능하고 의사소통하기 쉽게 만들기 위해 존재합니다. “여기서 어댑터를 사용했어”라고 말하면 동료는 수백 줄의 코드를 읽지 않아도 즉시 설계 의도를 이해합니다.

이 글에서는 실제 문제 해결에 초점을 맞춰, 풀스택 혹은 시니어 개발자를 목표로 하거나 이미 그 위치에 있는 모든 개발자에게 필수적이라고 생각되는 패턴들을 공유합니다.

Strategy

Um dos maiores sinais de débito técnico é aquele método que começa com um if e, seis meses depois, tem 15 else if ou um switch gigante.

Strategy separa a regra do contexto. Imagine um sistema de e‑commerce que precisa calcular o frete para diferentes transportadoras. Em vez de um emaranhado de lógicas dentro do serviço de checkout, você isola cada transportadora em sua própria classe.

Visão sênior

• Facilita o teste de cada estratégia isoladamente.
• Permite adicionar uma nova transportadora sem tocar no código que já está funcionando (Princípio Open/Closed).

Observer / Pub‑Sub

현대 세계에서는 모놀리식 및 동기식 시스템이 병목 현상이 됩니다. Observer 패턴(또는 메시징을 이용한 Pub/Sub 로의 진화)은 시스템의 각 부분이 서로 결합되지 않고도 무언가가 발생했음을 알 수 있게 합니다.

사용자가 구매를 완료하면 재고 시스템, 세금계산서 시스템, 마케팅 시스템이 알림을 받아야 합니다. 이러한 호출을 동기식으로 연결하면 이메일 서비스가 실패할 경우 전체 구매가 중단됩니다.

Visão sênior

• 회복력 있는 시스템을 설계합니다.
• 애플리케이션의 핵심은 주변 시스템에 대해 독립성을 유지합니다.
• 프론트엔드에서는 전역 상태와 이벤트를 통해 이를 매일 사용하고; 백엔드에서는 이벤트 중심 아키텍처의 기반이 됩니다.

Adapter

Adapter는 “경계” 역할을 합니다. 시스템이 이해할 수 있는 인터페이스를 만들고 외부에서 들어오는 것을 그 안으로 번역합니다.

시니어 관점

SMS 제공업체가 회사를 바꾸거나 API를 업데이트하면, Adapter만 수정하면 됩니다. 시스템의 나머지 부분은 변경을 전혀 감지하지 못해, 당신이 통제할 수 없는 외부 요인으로부터 도메인을 보호합니다.

초과 설계 방지

여기서는 경험 많은 전문가와 이론가를 구분합니다. 시니어가 빠지기 쉬운 가장 큰 함정은 초과 설계(과도한 엔지니어링)입니다.

• Abstração tem custo: 인지적 복잡성. Abstract Factory를 한 번도 두 번째 변형이 없을 상황에 적용하는 것은 시간과 자원의 낭비입니다.
• KISS (Keep It Simple, Stupid): 가장 단순한 해결책이 보통 가장 좋습니다.
• YAGNI (You Ain’t Gonna Need It): “언젠가 필요할지도 모른다”는 생각으로 무언가를 구현하지 마세요. 실제로 필요할 때 구현하십시오.

결론

이러한 패턴을 마스터하는 것은 완전한 도구 상자를 갖는 것과 같습니다. 하지만 목수가 전동 톱을 사용해 그림을 못 박지 않는 것처럼, 시니어는 문제에 맞는 올바른 도구를 선택합니다.

아키텍처 결정을 내리기 위해 정신적 명료성을 유지하려면 코드뿐 아니라 자신의 “머신”도 신경 써야 합니다. 건강과 퍼포먼스를 관리하는 것—예를 들어, 집중력과 인지를 날카롭게 유지하기 위해 오메가‑3 보충을 하는 것—이 결정적일 수 있습니다, 왜냐하면 복잡한 시스템을 설계하는 것은 고성능 정신 스포츠이기 때문입니다.

당신은요? 어떤 디자인 패턴이 여러분의 프로젝트를 구했나요 (또는 어디에 사용돼서는 안 되었는데 재앙을 일으킨 경우는?)? 댓글에서 아이디어를 나눠요!

Tags: SoftwareArchitecture DesignPatterns Fullstack Programming Seniority CleanCode