[쏙쏙 들어오는 함수형 코딩] chapter 8-9. 계층형설계

• 깨끗한 코드를 만들기위해 함수를 추출하는 방법을 배운다.
• 계층을 나눠서 소프트웨어 설계

소프트웨어 설계란? 코드를 만들고, 테스트하고, 유지보수하기 쉬운 프로그래밍 방법을 선택하기 위해 미적 감각을 사용하는것

계층형 설계

• 소프트웨어를 계층으로 구성하는 기술
• 각 계층에 있는 함수는 바로 아래계층에 있는 함수를 이용해 정의한다.

계층

• 비지니스 규칙
• 도메인 함수
• 카피온라이트
• 언어에서 지원하는 메서드/기능

step 1. 직접 구현

• 호출 그래프를 만들어 함수 호출을 시각화하기
• 서로 다른 추상화단계에있는 기능을 사용하면 직접구현패턴이 아니다.
• 함수가 모두 비슷한 계층에 있다면 직접 구현했다고 할수있음
• 같은 계층에있는 함수는 같은 목적을 가져야한다.
  • 비지니스규칙
  • 기본동작
  • 카피온라이트
  • js언어기능
• 각 계층의 추상화수준이 다르기때문에, 어떤 계층에있는 함수를 읽거나 고칠때, 낮은수준의 구체적인 내용은 신경쓰지않아도된다.
• 계층형 설계는 특정 구체화 단계에 집중할 수 있게 도와준다.
• 각 계층은 다른계층의 구체적인 내용을 몰라도된다!

step 2. 추상화 벽

• 어떤 계층은 중요한 세부 구현을 감추고 인터페이스를 제공한다.
• 각 계층에 해당하는 수준에서만 추상화단계를 생각하면된다.
• 추상화 벽에 있는 함수를 사용할때는 구현을 전혀 몰라도 함수를 사용할 수 있다.
• 추상화벽은 흔히 사용하는 라이브러리나 API와 비슷하다.
• 추상화 단계의 상위에있는 코드와 하위에있는 코드는 서로 의존하지않게 정의한다.!!!!!

언제 사용할까?

1. 쉽게 구현을 바꾸기위해
   1. 추상화벽으로 영역을 분리해놓으면 나중에 구현을 바꾸기 쉬움
2. 코드를 읽고 쓰기 쉽게 만들기위해
   1. 추상화벽을 사용하면 세부적인것을 신경쓰지않아도된다.
3. 팀 간에 조율해야할것을 줄이기위해
   1. 서로의 영역을 분리해놓으면 내부모듈만 수정하면되기때문에 조율할 시간을 줄일수있음
4. 주어진 문제에 집중하기위해
   1. 해결해야할 문제의 구체적인 부분을 무시할수있다

step 3. 작은 인터페이스

• 새로운 코드를 추가할 위치에 관한것
• 인터페이스를 최소화하면 하위 계층에 불필요한 기능이 쓸데없이 커지는것을 막을 수 있다.

---

• 추상화 벽에 코드가 많을수록 구현이 변경되었을때 고쳐야할것이 많다

step 4. 편리한 계층

• 자바스크립트 언어는 기계어에 대한 추상화 벽을 제공한다. 자바스크립트로 코딩할때 기계어를 생각하는 사람은 아무도 없다.
• 소프트웨어를 더 빠르고 고품질로 제공하는데 도움이되는 계층에 시간을 투자해야한다.

---

호출그래프를 통해 알수있는 정보

• 기능적 요구사항
  • 소프트웨어가 정확히 해야하는 일
• 비기능적 요구사항
  • 테스트를 어떻게할지, 재사용은 잘할수있는지, 유지보수하기 어렵지는않은지 > 어니언 아키텍처와 관련있음
  • 소프트웨어를 설계하는 중요한 이유!!
• 그래프의 가장 위에있는 코드가 고치기 가장 쉽다
  • 비지니스규칙처럼 자주 바뀌는 요구사항은 다른데서 많이 호출될일이없기때문에 수정에 대한 제약이 적음
  • 그래서 시간이 지나도 변하지않는 코드를 아래 계층으로 넣어야한다.
• 아래에 있는 코드는 테스트가 중요하다
  • 아래 함수는 잘 변경되지않기때문에, 테스트코드를 오래 유지할수있다.

느낀점

이번 강에서는 몇개의 핵심 키워드가 있었다.

추상화 벽

이 책을 2번째 읽는건데, 추상화 벽이라는 개념을 처음 배웠을때 리액트를 처음 배웠을때만큼의 큰 깨달음이있었다.

사실 이 개념을 익히기전에 우리는 추상화 벽을 항상 접해왔었다.

외부 라이브러리를 사용할때, 우리는 해당 라이브러리가 제공해주는 인터페이스를 사용하는데 그 내부구현에 대해서는 별다른 학습없이도 쉽게 사용할수있다. 이게 바로 추상화 벽이다.

 

모듈과 모듈간에 하나의 벽을 세우고, 인터페이스로만 소통을 하고 그 내부에 대해서는 외부에 노출하지않는다는 컨셉이 코드를 응집해줄수있겠다는 생각이 들었다.

 

코드 응집도라는 키워드로 찾아보니 한번 읽어보면 좋을 개념이있어서 가져와봤다.

[설계 용어] 응집도와 결합도

 

위 블로그 내용에서도 말하는것이 코드의 응집도와 결합도를 고려하면서 코드를 작성해야 코드의 유지보수를 용이하게 해준다고 하는데, 코드의 응집도를 높이고 결합도를 낮출수있게 도와주는게 추상화 벽이라고 생각한다.

 

특정 모듈의 내부구현이 외부로 노출되지않고, 해당 모듈에 필요한 기능이 다른 모듈에서 구현되지않도록 고려하면서 코드를 작성하는것이 추상화 벽을 세우는것이고, 이러한 고려가 응집도를 높이고 결합도를 낮추는 설계구조로 이어질것이다. 

 

추상화 벽의 가장 큰 장점중 하나라고 생각했던게,

내부구현이 변경되어도 해당 모듈을 사용하는 외부 모듈의 코드를 수정할 필요가없다는것이다.

외부모듈은 동일 input에 대해 동일한 output이 나오기를 기대하면되고,

모듈 내부에서 수정이 필요한 부분만 수정하고, 테스트하면 

해당 모듈을 사용하는 외부 모듈들에 대해서 테스트를 할 필요가 없어진다.

 

외부 라이브러리뿐만 아니라, 내가 작성하는 하나의 프로젝트내부에서도 추상화 벽을 세울수있다.

예를들어 class를 만들어보면서 해당 class의 내부 데이터 구조를 외부에 노출하지않으면서 외부에서 사용할 인터페이스를 정의하고, class 내부 구현을 여러 방식으로 변경해보면서 추상화벽을 더 견고하게 만들어보면 좋을것같다.

 

 

호출 그래프

https://ko.wikipedia.org/wiki/%ED%98%B8%EC%B6%9C_%EA%B7%B8%EB%9E%98%ED%94%84

 

위 예시 이미지처럼 여러개의 함수가 호출되는 계층을 시각화해서 표현한것이 호출 그래프이다.

 

호출 그래프관련된 내용을 읽을때 호출그래프를 만들어놓으면 좋은점이 비기능적 요구사항을 고려할수있다는건데,

쉽게말하면 테스트를 어떻게할지, 재사용은 잘할수있는지, 유지보수하기 어렵지는않은지에 대한 고려도 같이 할 수 있게되는것이다.

 

함수가 외부효과를 발생시키는지 여부에따라 테스트를 다르게 할수있고,

저수준에 있는 함수일수록 재사용가능한 함수로 만들려고 할것이고,

함수의 호출구조를 한눈에 볼수있어서 함수를 고치면 어디까지 영향을 주는지에 대한 파악도 쉬워질것이다.

 

그래서 호출 그래프의 장점에 대해서 다시한번 생각해볼수있었는데,

실제로 이걸 업무에 도입하는건 가능할까 하는 생각도 들었다.

 

프로젝트 전체에 적용하는것은 현실적으로는 힘들것같고, 복잡하고 큰 컴포넌트 레벨에서 한번 도입해보면서 감을 익혀가도 좋을것같음!