Layered architecture - 2/2

당신이 선택한 글이다. 악으로 깡으로 버텨라. 욕이 나온 사진을 써서 미안하다.

Why do you use this

사실 저거에 대한 사진을 찾고 싶었는데 제대로 안떠서 그나마 비슷한 저걸로 골랐다.

 

나는 너무 당연하게 생각하고 쓰고 있긴한데, 사실 왜 쓰는지 모르고 쓰면 너무 바보같기 때문에 바보가 아닌 척하기 위해 억지로 질문을 해봤다.

 

이 글을 쓴 계기가 신입에게 주어지는 첫 과제, React 프로젝트 이야기라는 영상을 본 것인데.

이 영상에서도 나오듯이 필요하기 때문에 쓰는 것이다.

 

많은 사람들이 이미 모듈별로 나눠서 코드를 작성하겠지만, 반대의 경우. 하나의 클래스 혹은 하나의 스크립트, 하나의 함수에 모든 기능을 다 넣은 경우가 있을 것이다. (혹시 당신이 그런 경우라면 가슴에 손을 얹고 잠시 지난 날을 반성하는 시간을 갖자.)

 

지난 날의 과오에 대해 묵념.

문제가 뭘까

4개의 기능을 하나의 모듈(함수, 스크립트, 클래스)에 넣은 프로젝트를 만들었다고 하자.

이 기능에 로그인, 닉네임 변경, 주소 변경 등등이 다 포함되었다.

 

당신이 만든 프로젝트가 로그인을 하고, 그 다음에 닉네임을 바꾸는 기능을 포함했다고 하자.

근데 닉네임 만드는 기능에서 자꾸 오류가 발생한다. 버그가 나서 의도한대로 동작을 안한다.

당신은 분노한 상태에서 디버깅을 하게된다. 왜 안될까.

 

만약 하나의 모듈에 모든 기능을 넣었다. 당신은 너무 행복하게도 로그인을 하고, 그 다음에 닉네임을 변경하면서 디버깅을 해야할 것이다.

(코드가 실행되려면, 시작점이 있어야되는데 하나의 모듈에 기능을 다 넣었으니 실행할 때마다 굳이 수정하지 않아도 되는 코드를 거쳐서 버그가 발생하는 지점까지 와야할 것이다. 이런 하지않아도 되는 일을 반복하는 과정에서 당신은 더 분노하게 될 것이다.)

 

더 이상 화내고 싶지 않아

clean-architecture-for-react-apps라는 글을 보면 아래의 사진처럼 클-린 아키텍쳐를 가져가라고 제안한다.

CLEAN architecture

또한 이러한 장점이 있다고 이야기한다. 그 중 몇개를 가져왔다.

 

쉬운 원인 찾기

Divide and conquer: 큰 문제를 해결하기 위한 최고의 방법은 해결하기 쉬운 작은 문제로 쪼개는 것이다.

우리는 의존성이 없는 레이어로 나누어(각 레이어에 존재하는 변수를 다른 레이어에서 사용하지 않는다고 이해하자.) 다른 레이어에 대해 신경쓰지 않을 수 있다.

교체

레이어는 다른 구현(레이어)로 쉽게 교체할 수 있다. 우리가 http 라이브러리를 매일 바꿔야하는건 아니지만, 그런 필요성이 생기면 http 레이어만 변경하면 된다.

테스트

각 레이어는 독립적이기 때문에 테스트가 용이해진다. 다른 레이어를 신경쓰지 않고, 테스트할 수 있게 해준다.

 

---

 

좀 더 구체적인 예시와 함께 글을 작성했으면 좋았을 것 같다.

추후 더 좋은 예시가 있다면 보완하도록 하겠다. 읽느라 고생했다. 난 잔다.

 

잠은 소중하다.