사용자의 불편함을 쉽게 개선할 수 있도록 변경이 자주 일어나는 (soft) 상황에서 기능이 추가될 때마다 함수 전체 (또는 클래스)를 다시 개편 해야 한다면 많은 시간과 노력이 필요하게 될 것이다.
이러한 상황을 방지하고자 회사에서는 정기적인 코드리뷰, 테스트코드, 리팩토링, 컨벤셩 정의 등을 통해 문제를 예방하고 빠르게 예상가능한 문제를 찾고자 한다.
소프트웨어에서도 서로 간의 종속성을 최소한으로 해둔다면 변경이 발생했을 때 다른 영역에 영향을 주지 않고 변경할 수 있도록 하는 것
도미노의 중간을 비워두는 것처럼 변경에 유연할 수 있는 구조를 만들기 위한 원칙이 바로 SOLID원칙.
코드라는 것은 글쓰기와 같아서 각자 주관적인 영역이 존재하지만 협업 시에 이 원칙에 크게 벗어나지 않으려는 노력을 해야한다는 정도로 이해하면 된다.
SOLID 원칙?
객체지향형 프로그래밍에서 파생된 원칙으로 함수형 프로그래밍에는 적용하기 좀 어렵다는 아쉬운 점이 있지만 5가지 원칙으로 코드를 조금 더 클린하게 작성할 수 있는 원칙.
SRP (Single Responsibility Principle) - 단일 책임 원칙
객체는 오직 하나의 책임을 가져야만 한다. (오직 하나의 변경의 이유를 가져야 한다.)
즉, 1개의 함수는 1개의 역할만을 수행하자
함수는 한 가지 작업을 수행해야 한다.
Good
함수를 잘게 쪼개고 명확하게 만들면 절대로 이 함수는 틀릴 수 없다! 라는 코드 조각들이 많아지게 되어 문제가 발생 했을 때 확인해야하는 코드의 양이 줄어 들게 됨
하지만 '굳이'? 라는 의견이 존재할 수 있지만 아래의 해당하는 함수들을 쪼개는 것이 좋다고 한다.
순수함수?
- 1개의 반환값이 존재
- 같은 인자를 넣었을 때 같은 값을 반환하고
- 함수 외부의 어떠한 값을 변환시키면 안 되는 함수
초간단예시 fuction Plus(x, y) { return x+y }
OCP (Open/Closed Principle) - 개방 폐쇄 원칙
소프트웨어의 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
트럭이라는 운송수단과 뒤에 달리는 기구를 분리/결합하는 구조를 만들어 새로운 목적에 해당하는 도구를 만들어야 할 때 트럭 전체를 다시 만들지 않고서 뒤에 달리는 장치만 새롭게 만들면 됨
OCP의 원칙의 의미는 새로운 기능의 추가가 일어났을 때에는 기존 코드의 수정없이 추가가 되어야하고, 내부 매커니즘이 변경이 되어야 할 때는 외부의 코드 변화가 없어야 한다 라는 것이다.
- 버그 수정이 아닌 새로운 기능을 개발할 때 기존에 개발된 함수를 수정하면서 코드를 개발하고 있다면 OCP 원칙을 위배한 코드를 작성하고 있을 확률이 엄청 높음
LSP (Lidkov Substitution Principle) - 리스코프 치환 원칙
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다는 설계를 참고
즉, 다형성을 유지할 수 있는 코드를 작성하라는 것
부모의 속성을 자식이 가질 수 없는 코드를 만들지 말라는 것
펭귄을 지우던가 fly()라는 기능을 앵무새에만 두던가
ISP (Interface Segregation Principle) - 인터페이스 분리원칙
사용자가 필요하지 않은 것들에 의존하지 않게 되도록 인터페이스를 유지하라 (인터페이스를 최대한 잘게 유지)
DIP (Dependency Invension Principle) - 의존관계 역전 원칙
"프로그래머는 추상화에 의존하고 구체화에 의존하면 안 된다."
"전기를 이용하기 위해서는 플러그만 꽂으면 된다. (추상화)."
플래그에서 "실제 전기배선이 어떻게 되던간에 사용자는 알 필요가 없다. (구체화)"
React 컴포넌트는 당연히 UI만 호출,
커스텀 훅을 만든 후 거기에서 useEffect를 통한 axios를 가지고 오면 되는데
여기서 그러면 useEffect에서 axios를 쓰던, 따로 빼서 쓰던 무엇이 다르냐? 하면
어느 곳, 어느 부분에서 에러가 발생했는지 확연하게 알 수 있기 때문
결론적으로, 추상화된 레이어를 두는 이유는 컴포넌트 입장에서는 데이터가 필요한 거지 그게 반드시 서버의 데이터일 필요는 없기 때문
이러한 레이러를 통해 언제든 서버가 아니라 로컬 mock데이터나 다른 방식으로도 사용하는 쪽의 코드를 변화없이 변경할 수 있게 됨
React 컴포넌트에서 axios를 호출하거나, fetch를 바로 호출하면 구체적인 부분에 의존을 하면 안 된다는 DIP원칙에 어긋나기 좋은 설계이고, axios를 다루는 모둘에서 컴포넌트의 props를 ㅈ조작하는 것은 레이어의 범위를 벗어나는 코드 역시 DIP에 어긋나는 설계.
출처 : https://velog.io/@teo/Javascript%EC%97%90%EC%84%9C%EB%8F%84-SOLID-%EC%9B%90%EC%B9%99%EC%9D%B4-%ED%86%B5%ED%95%A0%EA%B9%8C
