유효성 검사 함수 리팩토링 과정

유효성 검사 함수가 읽기 어려운 구조로 작성되어서, 읽기 쉬운 구조로 재구성하기 위해 고민을 시작
 
처음에는 복잡하지만 중복되는 코드들을 함수로 분리하는 것으로 시작해보려고 했는데
휴... 도전은 처참하게 오류와 함께 실패. 그리고 구조도 마음에 들지 않았다.
 
무엇이 문제인지(마음에 들지 않았는지) 짚어봤다.
 
1. if-else
2. if구문의 중첩
3. 하나의 기능이 많은 역할을 맡음
 
[수정]
1. if-else보다 조건을 파악하기 명확하고, 읽기에 편한 switch-case구문을 사용했다.
 - 타입을 확인하고, 그 타입이 Array인지, Object인지 확인하는게 if구문의 조건이었다.
 - 두 가지를 확인해야 해서, 복잡해 보였다고 판단.
 - switch(타입을 확인), case "특정 타입" 으로 분리했다.
 - switch구문으로 전환하면서, 어떤 타입인 경우인지 명확하고 쉽게 구분할 수 있었다. 더욱이 원시값을 확인하는 부분도 같이 묶어서 표현할 수 있었다.

switch (getType(nextState)) {
  case "Array":
    //
    break;
  case "Object":
    //
    break;
  case "Boolean":
  case "Number":
  case "String":
    //
    break;

 
 
2. 인덴트의 깊이를 덜어내기 위해, 무엇때문에 인덴트가 자꾸 들어가게 되는지 살펴봤다.
 - 첫번째: early return 이 가능했는데, 그렇게 하지 못했다. 만약 throw Error가 발생할 수 있는 경우 코드를 상단으로 끌어올렸다.
 - 두번째: Object인 경우 하는 일이 너무 많았다. 그래서, Array인 경우와 원시값인 경우의 case로 넘기기로 했다. (재귀 호출)
 - 세번째: case에 Null과 Undefined를 추가했다. 그래서, isNullish를 확인하는 것으로 분리했다.(Object인 경우에 수행했던 조건이었는데, Null과 Undefined에 역할을 위임)
 
 
기본을 지키지 못했던 문제였지만 앞으로 어떻게 고민해야 할지 알 것 같고, 팀원들에게 이해하기 좋은 코드를 보여주기 위해 계속 고민해야겠다.