오늘 배운 것

React 프로젝트 리팩토링

postCSS

module 화랑 nesting 적용 해봄.

https://github.com/velopert/react-tutorial/blob/master/styling/04-postcss.md

git

git merge

써봐도 써봐도 안쓰면 까묵는다ㅋㅋㅋㅋ

merge 할 때 베이스로 하고 싶은 브랜치로 checkout 해서
말 그대로 git merge (merge 할 브랜치)
하면 끝

conflict 있으면 잘 보고 지우면 되고
없으면 그냥 고대로 merge 끝이다~

프로그래밍 기본 지식

주의! 이 글은 디자인 패턴에 대한 지식이 전무한 사람이 쓴 글입니다. 참고 금지

디자인 패턴

디자인 패턴이란

소프트웨어 개발에 있어서 소스나 리소스 구조적인 부분에서 생기는 문제를 해결하도록 탄생한 개발 방법론

코드를 어떻게 짤지, 프로그램 구조를 어떻게 짤지에 대한 방법론.

코딩/프로그래밍하는 것이 건물을 짓는 것이라면 디자인 패턴을 짜는 것은 건축 설계로 생각하면 될까.

디자인 패턴이 나오게 된 이유

• 프로그램을 만드는 초기에는 돌아가기만 하면 되는 줄 알고 짜게 된다.
• 하지만 최근의 서비스들 처럼, 프로그램이 점점 커짐에 따라 유지보수와 기능 추가들이 더더욱 필요한데, 막 짠 코드를 보니까 한 파일 내에 2만 줄의 코드가 뒤엉켜 있는 것을 발견할 것이다.
• 따라서 이러한 문제를 프로그램 개발 초기부터 방지하기 위해 이 "프로그램 짜는 방법론" 즉, 디자인 패턴이 발전하게 된 것. ("우리 미리미리 유지보수하기 쉽게 코드 역할별로 구역을 나누어보자")
• 그렇기 때문에 방법론은 여러가지가 존재하며 이건 이거다 처럼 딱딱 떨어지도록 정해진 것이 아니다. 또한, 한 프로젝트에서 패턴을 한가지, 한 개만 적용할 수 있는 것 또한 아니다.
• 어쨌건 간에 그 중에서도 프로그램의 유지보수가 더 좋게 만들어진(똑똑한 개발자 선배들이 만들어 놓은) 패턴이 존재할 것.
• 그것이 바로 익히 들은 MVC, MVVM, MVP 이다. (이거 보다 훠어얼씬 더 많다.)

MVC / MVVM

MVC 패턴
웹 프레임워크에 널리 사용된다. 다음으로 나올 MVP, MVVM의 초석이 되는 패턴이다.
대부분의 웹 프레임워크(Django, Ruby on Rails, Sysmfony, Spring 등등)가 이 패턴을 가지고 있다.
Model, View, Controller로 나누어서 프로그램을 구성한다.

• View
  사용자에게 보이는 화면만 구성되어 있는 곳이다.(웹 개발에서보면 HTML, CSS 영역을 생각할 수 있다.)
  하지만, 이 웹에서 JS 동작을 구성하는 데에 있어서도 디자인 패턴이 적용될 수 있으므로 View안에 또 다른 디자인 패턴이 적용이 될 수 있다는 것이다. (유연적으로 생각할 필요가 있을 것 같다.)

• Model
  사용할 데이터가 저장되어 있는 곳.(그렇다고 해서 데이터베이스라는 것은 아니다.)
  메모리에 있는 데이터들을 가지고 있는 곳이라고 생각하면 될 듯하다.

이제 이것에다가 플러스 알파로 Presenter, Controller, View Model등이 합쳐져서 디자인 패턴을 형성한다.

• Controller
  View와 Model을 변화시키는 곳.
  비즈니스 로직이 여기 위치한다.
  모델을 호출해서 데이터를 변경할 수도 있고, View에다가 색상, 움직임을 명령하는 코드가 들어가 있다.

  -> 여기서 잠깐!
  비즈니스 로직이 뭔데?
  Business Logic: 데이터를 보여주기 위해서 데이터베이스를 검색하는 코드 및 GUI(Graphic User Interface) 화면에서 새롭게 발생된 데이터를 데이터베이스에 저장하는 코드 등 실제적인 작업을 하는 코드

  이와 상응하는 개념으로는 프레젠테이션 로직이 있다.
  Presentation Logic: 실제 눈에 보이는 GUI(Graphic User Interface) 화면을 구성하는 코드

동작
1) Controller로 사용자의 입력이 들어온다.
2) Controller는 Model에 데이터를 업데이트하고 요청한다.
3) Model은 해당 데이터를 보여줄 View를 선택하여 화면에 나타낸다.

MVC 패턴의 장점
비교적 직관적인 구조이기 때문에 굉장히 많이 사용된다.
디자이너와 협업하기 좋다.(완전히 화면만 담당하는 디자이너 혹은 퍼블리셔가 컨트롤러를 건드릴 이유가 없기 때문에, 구역이 잘 나누어져 있기 때문에)

MVC 패턴의 단점
컨트롤러에 비즈니스 로직이 몰리는 경향이 있다.
따라서 프로젝트가 더 커지면 이 패턴 또한 모듈화를 한 이유가 없어진다. 어차피 여기서도 만 줄인데;;
뷰와 모델의 의존성 때문에 다른 프로젝트에 적용하기가 쉽지 않다.
서로 없어서는 안되는 성향을 가지게 되면서 모듈화의 장점이 사라지는 것이다.

따라서 이러한 View와 Model의 의존성을 해결하기 위해 MVP 패턴이 등장했다.

MVP
MVP는 Model과 View는 MVP와 같다. 하지만, Controller 대신 Presenter가 존재한다.

Presenter는 View에서 요청한 정보를 Model로 부터 가공해서 View로 전달하는 부분

MVC와 다르게 View에서 사용자 입력을 받는다.
이후 Model과 View는 Presenter와 상호 동작을 한다.
따라서 이 Model 과 View의 의존성이 사라지게 되는 것이다.

동작
1) view로 사용자의 입력이 들어온다.
2) view는 Presenter에 작업을 요청한다.
3) Presenter에서 필요한 데이터를 Model에 요청한다.
4) Model은 Presenter에 필요한 데이터를 응답한다.
5) Presenter는 View에 데이터를 응답한다.
6) View는 Presenter로부터 받은 데이터로 화면에 나타낸다.

장점:
View와 Model의 의존성이 사라진다.

단점:
대신 View와 Presenter가 1:1로 강한 의존성을 가지게 된다.

따라서 이러한 단점을 보완하기 위해 MVVM이라는 디자인 패턴이 등장한다.

MVVM
역시 Model과 View는 동일하다.
그러나 Presenter 대신 ViewModel이 존재한다.

ViewModel은 View만을 위한 Model이다.

동작
1) View에서 사용자 입력이 들어온다.
2) ViewModel에 명령을 한다. (command 디자인 패턴 사용)
3) Model은 ViewModel에 필요한 데이터를 응답한다.
4) ViewModel은 응답받은 데이터를 가공해서 저장한다.
5) View는 ViewModel과의 Data Binding으로 인해 자동으로 갱신된다. (Data Binding 디자인 패턴 사용)

장점
View와 Model의 의존성을 없앤다.

단점
View Model의 설계가 까다롭다.

그래서 프론트엔드 지망생인 내가 뭘 써야한다고..?

지금 당장 뭘 쓰라는 건 아니다. (물론 디자인 패턴 적용해봤다고 하면 좋아하는 데도 있다고 들었지만)

현재 웹 서비스드를 거대화되면서 기존의 MVC에서 MVP,MVVM 패턴을 요하는, 또 실제로 적용하는 곳도 많다.

일단 개념들은 잡아두고, 이를 염두에 두면서 ? 염두해두면서

좋은 코드를 보면 감을 잡아갈 수 있지 않을까...

아직 내 코드는 디자인 패턴이고 뭐고 그냥 냅다 적어버린다~
그래서 이번에 리팩토링한답시고 건드려봤더니 진짜 엮여있는 코드들이 많아서 분리하는 게 너무 힘들다.. ㅠㅠㅠ

[참고 및 출처]
https://www.youtube.com/watch?v=YsKh5pgvfmA
https://swimjiy.github.io/2019-05-28-web-mvc-mvp-mvvm
https://brunch.co.kr/@oemilk/113
https://magi82.github.io/android-mvc-mvp-mvvm/
https://beomy.tistory.com/43