면접을 보면서 내가 몰랐던 지식이 너무 많아 더 배워야겠구나 느꼈고,
질문받은 내용들은 프론트엔드 개발자로서 알아야하는 지식들이라 생각하며 내용들을 정리해보려고한다.
먼저 디자인패턴!
그동안은 개발공부를 할 때 디자인패턴? 그게뭐야..작동이 되면 그만이지..이런 생각으로 흐린눈하면서 공부해왔는데 같이 일하는 협업의 측면에서도 그렇지만 이제는 내가 쓴 코드도 다시 돌ㅇ아보면 까먹고 이런 경우가 허다해서 나를 위해서라도 공부해야할 필요성을 느꼈다.
소프트웨어 아키텍쳐 vs 디자인 패턴
소프트웨어 아키텍쳐
- 유연성, 확장성, 실현가능성, 재사용성, 보안성 등의 소프트웨어 특성을 기술적, 사업적 기대사항에 맞게 구조화된 솔루션으로 만들어가는 과정
- 아키텍처 특성 + 아키텍처 결정 + 설계원칙
- 아키텍처 특성 : 시스템의
성공 기준(성능, 확장성, 신뢰성, 활용성, 유지보수성, 접근성, 보안성, 사용성 등) - 아키텍처 결정 : 시스템 구축에 필요한
규칙정하기,제약조건형성 - 설계 원칙 : 시스템 구축에 필요한
가이드라인정하기
소프트웨어 디자인 패턴
- 어떻게 코드를 작성할것인가에 대한 방법론
- 각각의 모듈이 어떤 역할을 하는지, 클래스 범위, 함수 목적 등 코드레벨의 디자인
- 반복되는 문제 상황들을 최적화된 방법으로 해결하도록 돕는 역할
대표되는(된다고 생각이 드는...) 디자인 패턴
MVC 패턴
굉장히 많이 들어온 바로 그 패턴..! Model, View, Controller로 역할을 구분지어 분류한것
- Model : 데이터와 비지니스의 로직, 데이터를 처리 및 가공
- View : 사용자가 보는 화면, UI
- Controller : Model과 View 사이에서 조율하는 역할
View로부터 사용자의 액션이 들어오고, Controller가 해당 액션에 대한 업무를 처리하는 Model을 호출하며, Model은 해당 업무에 대한 데이터를 처리하고 그 결과를 Controller가 어느 View를 통해 보여줄지 결정해서 최종적으로 사용자에게 보여진다.
다른 블로그를 보며서 View에서도 필요한 데이터가 많고, 이를 위해서 매번 Controller에 접근해야 데이터를 컨트롤 할 수 있어서 프론트엔드 측면에서 View를 단순히 화면에 보여지는 것만으로 다룰 순 없다는 말을 보고 공감이 갔다. 지금까지 공부를 하며 MVC패턴은 그 개념에 대해 많이 접해봤지만, 막상 실습이나 프로젝트를 진행할 때는 이걸 대체 어떻게 분리시켜야하지..? 새로운 파일을 굳이 만들어야하나..?이 생각이 많았는데 내 생각도 오히려 MVC패턴으로 프론트엔드 개발자가 개발을 하면 Controller가 많이 커질 것 같아서 굳이 싶다..!(내 의견...)
MVVM 패턴
이것도 MVC를 공부하면서 함께 많이 봐온 패턴인데 항상 View Model의 개념이 너~무 헷갈린다. 대체 뭘 하는 자식이냐..
- View : MVC와 마찬가지로 사용자가 보는 화면, UI, 액션을 받는 것
- Model : 실제 데이터, 비지니스 로직
View Model: 뷰가 사용할 메서드와 필드를 구현, 뷰에게 상태 변화를 알리는 것
사실 뷰 모델이 하는 역할이 정확히 이해가 안갔다. MVC에서는 모델이 데이터를 가공 및 처리하는데, 뷰모델이랑 모델이랑 뭐가 다른건지 이해가 안갔는데 일반적으로 뷰 모델과 뷰는 일대다 관계를 형성한다는 말을 듣고 감이 조금 왔다.
이런 식으로 뷰(C)에서 모델A와 모델B의 데이터를 모두 활용한 데이터가 필요하면 뷰에서 두개의 데이터를 가져와 처리하는게 아니라 뷰 모델에 두데이터를 가공해 하나의 데이터로 만들고 뷰로 뿌려주기!!
그리고 뷰와 뷰모델은 데이터바인딩 되어있는데, 데이터 바인딩은 데이터를 제공하는 자와 그 데이터를 사용하는 자를 연결시켜 동기화되도록 하는 방식이다.이건.. 모델에서 데이터가 변경되면 View도 자동으로 바뀌는 것이라 한다.
Redux와 Flux 패턴
Flux는 단방향으로 흐름을 제어하고 동작하게끔 하는 패턴이다. View에서 어떤 입력으로 Action을 호출하면, 그 Action이 Dispatch를 통해 다시 store에 데이터를 전달하고 store에 변경사항이 있으면 View가 변하는 구조이다.
이런 Flux 패턴을 리덕스에서 활용한다! 기존에 props를 계속 전달하는 props drilling의 문제점을 해결할 수 있다. View단에서 UI구성에 필요한 데이터들을 상태(state)라고 하고, 이런 상태들을 관리하는 것이 상태관리인데 비지니스 로직에서 완전히 View를 분리시킬 수 있다.
하지만 단점으로는 보일러플레이트가 너무 많다.
보일러 플레이트
- 묻지도 따지지도 않고 따라적는 코드!
- 수정없이 반복적으로 사용되는 코드
- 리덕스에선 액션타입, 액션생성함수, 리듀서 같은 반복적으로 적어야하는 코드들
이런 보일러플레이트를 줄이기 위한 방법으로 toolkit을 사용하기도 한다.
Atomic 패턴
View를 원자에서 페이지까지 작은것들을 점점 결합해서 큰 단위의 View를 만드는 것
- 원자 : button, input, font등 가장 작은 구성 요소
- 분자 : 여러 원자 요소들의 구성, 여기서부터 복잡한 요소를 구성하고 재사용 하기 시작
- 유기체 : 사용자에게 의미있는 정보를 제공하거나 인터랙션 하는 인터페이스를 구성
- 템플릿 : 실제 콘텐츠가 입혀지기 전에 정해지는 와이어프레임
- 페이지 : 완성된 View
이런 아토믹 패턴은 Recoil 라이브러리에 도입되었는데 Recoil은 Redux보다 간단한 문법으로 컴포넌트 외부의 공통 데이터를 set,get 할 수 있으며 동기화도 가능하다.
Recoil에는 Atom과 Selector라는 개념이 있는데, Selector는 다른 atom이나 selector를 입력으로 받아들이면서 상위 atom이나 selector가 업데이트 되면 하위도 다시 실행되면서 컴포넌트들도 리렌더링된다.
(리코일에 대해서는 추후 공부해보자..!)
이렇게나 디자인패턴이 많다니..아직 완벽하게 이해한건 아니고 이걸 어떻게 적용시켜야할지는 감이 살짝 안오지만 한 번 읽어두면 다른사람의 코드를 읽거나 나중에 반드시 써먹을 일이 생길 것 같아서 꾸준히 읽어봐야겠다
