▲
GN⁺ 4달전 | parent | ★ favorite | on: Patterns.dev(patterns.dev)
Hacker News 의견들

  • 예전 직장에서 .NET 엔터프라이즈 앱을 개발할 때는 디자인 패턴이 정말 유용했음
    여러 팀이 같은 패턴을 쓰니 코드가 익숙했고, 새 프로젝트도 일관된 구조를 가졌음
    하지만 지금은 10년 넘은 JS 앱을 다루는데, Java EE 스타일의 getter/setter 남용과 복잡한 팩토리 구조 때문에 오히려 해로움
    패턴을 왜 쓰는지 이해하지 못한 채 남용하면, 단순히 읽기 쉬운 코드보다 훨씬 나쁜 결과를 낳음 (YAGNI 원칙을 떠올림)

    • 패턴은 ‘만드는 것’이 아니라 ‘발견하는 것’이라 생각함
      개발자라면 언젠가 Adapter, Builder, Iterator 같은 구조를 자연스럽게 떠올리게 됨
      디자인 패턴의 진짜 가치는 이런 발견된 패턴에 공통 언어를 부여해 서로 쉽게 소통할 수 있게 하는 데 있음
    • 많은 패턴은 C#이나 Java처럼 제약이 많은 언어에서만 의미가 있음
      C, Go, JavaScript처럼 단순한 언어에서는 훨씬 간단하게 해결할 수 있음
    • 엔터프라이즈 환경에서 온 개발자들이 JS에서도 같은 OOP 패턴을 억지로 적용하려는 걸 자주 봄
      언어의 철학과 맞지 않음
    • 나도 예전에 좋은 의도로 패턴을 적용했다가 유지보수 악몽을 만든 적이 있음
      처음엔 깔끔해 보여도 시간이 지나면 로직이 분산되고, 새 요구사항이 들어오면 패턴이 깨지기 쉬움
      결국 단순한 switch문이 그리워짐
    • 패턴이 쓸모없다고 말하는 사람들 중엔 대규모 시스템 경험이 없는 경우가 많음
      작은 앱만 만든 사람과 초고층 빌딩을 짓는 사람의 관점 차이 같음

  • 예전에 Yahoo Design Pattern Library가 있었음
    UX 패턴 중심이었고, 사용자 행동(예: 평점 매기기)을 유도하는 다양한 사례를 잘 정리했음
    원본 링크 / 웹 아카이브

    • 비슷한 오픈소스 프로젝트로 The Component Gallery가 있음
      90개 이상의 디자인 시스템의 UI 컴포넌트를 모아둔 저장소로, a11y/ARIA 가이드라인 학습에도 좋음
      component.gallery
    • “accordion”, “carousel” 같은 용어가 이 라이브러리 덕분에 표준화되었음
      공통 언어가 생산성을 높였음
    • 옛날 웹의 감성이 느껴져서 향수가 밀려옴
    • YUI도 당시엔 시대를 앞서 있었음
    • Yahoo 엔지니어링은 정말 훌륭했는데, 경영 실패로 무너진 게 아쉬움

  • 좋은 자료 모음이라 북마크에 추가했음
    비슷한 사이트를 공유함

  • 경력이 쌓일수록 디자인 패턴 의존도가 줄어듦
    주니어는 패턴을 배우면 경력 지름길이라 생각하지만, 오히려 복잡성을 키우는 경우가 많음
    진짜 중요한 건 문제의 본질과 데이터 구조를 이해하는 것임
    예를 들어, 두 배열의 공통 항목을 찾을 때 HashMap을 이용해 O(n) 으로 줄이는 단순한 패턴이 훨씬 유용함
    이런 건 이름도 없지만 실무에선 매일 쓰는 핵심 패턴임
    결국 중요한 건 원리와 맥락, 교과서적 형태가 아님

    • 패턴은 공통 언어로서 가치가 있음
      “싱글턴을 만들었다”고 말하면 바로 이해되니까
      하지만 도구를 맹신하는 건 문제임
    • 위에서 말한 HashMap 활용은 DB 세계에선 hash join이라 부름
      Postgres 쿼리 플래너에서도 볼 수 있음
    • “팩토리” 같은 용어를 쓰는 게 부끄럽진 않음
      다만 코드에 이름 붙일 때는 설명적으로 쓰는 게 좋음
    • HashMap을 이용한 최적화는 동적 프로그래밍의 한 형태로 볼 수도 있음
      Leetcode 연습할 때 익혀두면 좋음
    • 디자인 패턴 자체보다 패턴을 어떻게 적용하느냐의 패턴이 더 중요함
      기술적 패턴뿐 아니라 조직적 패턴도 다루는 책으로
      Organisational Patterns (James Coplien, Neil Harrison)을 추천함
      요약 링크

  • 대학 시절 우연히 Ralph Johnson이 직접 가르친 패턴 수업을 들었는데,
    인생에서 가장 유용한 수업 중 하나였음
    Ralph Johnson 위키

  • “Design Patterns are a sign of missing language features”라는 말이 있음
    즉, 언어가 충분히 표현력이 있었다면 패턴이 필요 없었을 수도 있음
    관련 자료: C2 Wiki, Norvig 논문, Medium 글

  • 이 사이트는 잘 정리된 튜토리얼 모음이지만, Christopher Alexander의 『A Pattern Language』 처럼
    패턴 간의 계층적 연결 구조를 보여주지 않아 아쉬움
    원래 패턴은 상위–하위 관계 속에서 의미가 생기는데, 기술 서적은 그 맥락이 빠짐
    각 패턴이 어떤 문제를 해결하는지도 더 명확히 제시되면 좋겠음

    • 『A Pattern Language』의 예시를 보면, 각 패턴이 다른 패턴들과 유기적으로 연결되어 있음
      예를 들어 “Short Passages”는 “Flow Through Rooms”, “Building Thoroughfare” 등과 이어짐
      이런 구조가 패턴 언어의 진짜 힘임

  • 패턴을 남용하면 느리고 유지보수 어려운 코드가 됨

    • 패턴은 문제 해결 과정에서 자연스럽게 발견될 때 가장 효과적임
      존재하지 않는 문제를 미리 해결하려다 복잡해짐
    • 결국 적절히 사용할 때만 빛남

  • POSD(Principles of Software Design) 관점에서 유용한 패턴은 다음과 같음

    • Module Pattern
    • Factory Pattern (factory functions)
    • Mediator/Middleware Pattern (function pipeline 형태)
    • Hooks Pattern
    • Container/Presentational Pattern
      반면 Singleton, Mixin, Observer 등은 복잡도 증가나 전역 상태 의존을 유발하므로 주의해야 함
    • POSD가 무엇인지 묻는 댓글이 있었음

  • 이 사이트는 깊이보다 넓이 위주로 보여서 2017년 느낌이 남
    진짜 중요한 건 immutable data를 다루는 기본기를 익히는 것임
    for문 없이 array 메서드만으로 코드를 짜보는 연습이 큰 도움이 됨

    • 예전에 ClojureScript를 써봤는데, 불변 데이터 다루기에 좋았음
      JS에서는 Object.freeze로는 한계가 있고, ramdajs처럼 새 객체를 반환하는 접근이 현실적임
      JS의 최신 문법 덕분에 ramdajs의 일부 함수만 여전히 유용함
    • 이 글을 보고 나만의 패턴 문서화를 해보고 싶다는 생각이 듦