디자인 패턴

GitLab 프론트엔드 개발에서 권장되는 디자인 패턴과 안티패턴을 설명합니다.

이 페이지에서는 권장 디자인 패턴과 안티패턴을 다룹니다. 이 문서에 디자인 패턴을 추가할 때는 해결하는 문제 를 명확히 기술하세요. 디자인 안티패턴을 추가할 때는 방지하는 문제 를 명확히 기술하세요. 패턴 # 다음 디자인 패턴은 공통 문제를 해결하기 위한 권장 접근 방식입니다. 특정 패턴이 해당 상황에 적합한지 평가할 때는 적절한 판단이 필요합니다. 패턴이라고 해서 반드시 모든 문제에 좋은 해결책은 아닙니다. 안티패턴 # 안티패턴은 처음에는 좋은 접근 방식처럼 보일 수 있지만, 이점보다 더 많은 문제를 초래한다는 것이 입증되었습니다. 이러한 패턴은 일반적으로 피해야 합니다. GitLab 코드베이스 전반에 걸쳐 이러한 안티패턴의 과거 사용 사례가 있을 수 있습니다. 이러한 레거시 패턴을 사용하는 코드를 다룰 때 리팩토링 여부를 결정할 때는 적절한 판단 을 활용하세요. 새 기능의 경우 안티패턴이 반드시 금지되는 것은 아니지만, 다른 접근 방식을 찾는 것을 강력히 권장 합니다. 공유 전역 객체 (Shared Global Object) # 공유 전역 객체(Shared Global Object)는 어디서든 접근할 수 있어 명확한 소유자가 없는 인스턴스입니다. 다음은 Vuex Store에 이 패턴을 적용한 예입니다: const createStore = () => new Vuex.Store({ actions, state, mutations }); // Notice that we are forcing all references to this module to use the same single instance of the store. // We are also creating the store at import-time and there is nothing which can automatically dispose of it. // // As an alternative, we should export the `createStore` and let the client manage the // lifecycle and instance of the store. export default createStore(); 공유 전역 객체는 어떤 문제를 일으키나요? # 공유 전역 객체는 어디서든 접근할 수 있어 편리합니다. 그러나 편의성이 항상 그 높은 비용을 상쇄하지는 않습니다: 소유권 없음. 이러한 객체에는 명확한 소유자가 없으므로 비결정적이고 영구적인 수명 주기를 갖게 됩니다. 이는 테스트에서 특히 문제가 될 수 있습니다. 접근 제어 없음. 공유 전역 객체가 일부 상태를 관리할 때, 이 객체에 대한 접근 제어가 없기 때문에 매우 버그가 많고 어려운 결합 상황이 발생할 수 있습니다. 순환 참조 가능성. 공유 전역 객체는 공유 전역 객체의 하위 모듈이 자기 자신을 참조하는 모듈을 참조할 수 있기 때문에 일부 순환 참조 상황을 만들 수 있습니다(예시는 이 머지 리퀘스트 참고). 다음은 이 패턴이 문제적으로 식별된 과거 사례입니다: IDE에서 전역 Vuex Store 참