성격 유형 검사 문제 풀이 및 README 수정

[ssi02014]

새롭게 추가된 문제 풀이

• level1 / 성격 유형 검사하기 390a26b
• 풀이 및 README 검토 부탁드립니다 🙇‍♂️

참고

문제 링크

[codeisneverodd]

좋은 풀이 잘 보았습니다!! 개별적으로 남긴 리뷰 외에도 다른 방법으로 풀어보았으니 참고 해보셔도 좋을 것 같아요!

README 확인했습니다 ㅎㅎ 감사합니다 😄

function solution(survey, choices) {
  const points = [-3, -2, -1, 0, 1, 2, 3];
  const types = ['RT', 'CF', 'JM', 'AN'];
  const pointBoard = types.reduce((a, key) => ({ ...a, [key]: 0 }), {});
  survey.forEach((key, i) => {
    const point = points[choices[i] - 1];
    Object.keys(pointBoard).includes(key) ? (pointBoard[key] += point) : (pointBoard[key[1] + key[0]] -= point);
  });
  return types.map(type => (pointBoard[type] <= 0 ? type[0] : type[1])).join('');
}

function solution(survey, choices) {
  const points = [-3, -2, -1, 0, 1, 2, 3];
  const types = ['RT', 'CF', 'JM', 'AN'];
  const pointBoard = survey.reduce((a, key, i) => {
    if (types.includes(key)) {
      a[key] = (a[key] || 0) + points[choices[i] - 1];
      return a;
    }
    const rKey = key[1] + key[0];
    a[rKey] = (a[rKey] || 0) - points[choices[i] - 1];
    return a;
  }, {});
  return types.map(type => (pointBoard[type] <= 0 || !pointBoard[type] ? type[0] : type[1])).join('');
}

[codeisneverodd]

"객체는 순서를 보장하지 않음"

Object 객체는 순서를 보장하지 않습니다.
대부분의 모던 브라우저는 기존의 순서를 유지하고, 이로부터 생성된 Entries도 그 순서가 유지되기는 하지만 순서를 확신할 수 없습니다.
따라서 위와 같은 방식은 다른 환경에서 동작하지 않을 가능성이 있기 때문에, pointBoard를 배열로서 선언하여 사용하는 방식이나, 서로 연관있는 값들을 순서가 아닌 객체로서 묶어서 사용하는 방식을 권장드립니다.

[ssi02014]

피드백 감사합니다 말씀듣고 배열로도 좋고 Map 생성자 사용해도 좋을 것 같다는 생각이 들었네요 👍
그런데 Object가 삽입 순서를 보장하지 않는다는 알고있었는데, 이 문제에서처럼 초기에 선언할 때도 그게 관련있는건지 😮

[codeisneverodd]

'선언할 때 key가 바뀌지 않는다는 말'을 이해하지 못했어요! 다시 설명해주실 수 있나요? @ssi02014

[codeisneverodd]

제가 알기론 ECMAScript 상의 지침이 없고, 브라우저마다 다른 것으로 알고있습니다! test 를 유사배열객체로 선언하지 않는 이상 숫자로 되어있는 key 값들도 순서의 의미를 가지지 않기 때문에, 브라우저마다 서로 다른 key 순서를 가져도 무방할 것 같습니다! 애초에 Object 의 key 값들에는 순서가 없으니까요!

[codeisneverodd]

"함수형 프로그래밍"

pointBoard의 키가 적기 때문에 위와 같은 방법으로 할 수 있습니다. 다만 키가 많아지는 경우 위와 같이 직접 적어주기 어렵고, 코드 또한 간결하지 않게됩니다. pointBoard를 만들기 위한 방법으로 다음과 같은 방법도 고려해보세요!

7-28라인을 아래와 같이 간단하게 나타낼 수 있습니다. 단, 모든 키값의 생성이나, 순서를 보장하지 않습니다.

const pointBoard = survey.reduce((a, c, i) => {
  const key = choices[i] < 4 ? c[0] : c[1];
  a[key] = (a[key] || 0) + points[choices[i] - 1];
  return a;
}, {});

[ssi02014]

좋은 풀이 잘봤습니다 🙇‍♂️ 단순 문제 요구사항에 맞추는걸 넘어서 다른 부분까지 채운 풀이를 하셨군요 👍

정말 깔끔하네요 도움이 많이 됐습니다 그런데 이번처럼 깔끔하게 나오는거 제외하고 가끔 저는 명령형이 오히려 가독성이 좋을 때도 있어서 꼭 선언형(함수형) 처럼 작성해야되냐?는 고민이 좀 되네요 🤔 어떻게 생각하시나요??

[codeisneverodd]

동의합니다! 명령형이 오히려 가독성이 좋을때도 있다고 생각해요 😄
하지만 대부분의 경우 함수형(선언형 프로그래밍의 일종)이 더 가독성이 좋을 때가 많다고 생각해요! 명령형은 코드의 흐름이 길어질 수록 파악하기 어려운 경우가 많은 것 같습니다.
함수형의 가독성이 떨어지는 경우는 고차함수에 대한 이해도가 부족한 것에서 오는 경우가 많은 것 같아요!
프론트엔드를 희망하고 계신다면 함수형으로 작성해야할 경우가 많기 때문에 저는 함수형으로 최대한 풀어보려고 노력하고 있습니다!!
코테를 볼 때는 생각이 잘 안나서 명령형으로 풀 때도 있지만, 리팩토링 할 때는 반드시 함수형으로 바꾸려 노력하는 편이에요 👍

[ssi02014]

코멘트 주신 풀이 잘봤습니다 🙇‍♂️ 그런데 forEach 또는 reduce 내부에 includes를 호출하는건 시간복잡도 상 비효율적이지 않을까요? (forEach, reduce 모두 O(N) 시간복잡도를 가지고, includes도 최악의 경우 O(N)) 물론, 올려주신 풀이는 types의 조건이 4개밖에 없긴하지만, 체크해야되는 type이 많아지면 높은 시간복잡도를 가질 것 같다는 생각이 드는데 이 부분에대해서 어떻게 생각하시는지 의견이 궁금합니다 🙆‍♂️

Object.keys().includes() 같이 메서드 체이닝을 한 경우에도 최악의 경우 O(2N)의 복잡도가 발생해서 forEach 내부에서 사용하면 시간복잡도 상 비효율적일 것 같다는 생각이 들었습니다 ! return 하는 map().join() 부분도 비슷한 의견입니다

[codeisneverodd]

@ssi02014 효율성 부분에 대한 의견에 전적으로 동의합니다!
다만 저는 프론트엔드에 맞는 코드를 짜려고 노력해요! 프론트엔드는 백엔드와 달리 모수(다루어야할 데이터의 총량)이 적은 경우가 많습니다. 화면에 그리기 위한 데이터만 처리하면 되니까요!
따라서 복잡도 보다는 코드의 간결성, 가독성, 유지보수성에 집중하고 있어요! 그렇지만 코딩테스트 문제인 만큼 @ssi02014 님의 의견에 동의합니다 😄

[codeisneverodd]

함수형 프로그래밍에 관심 있으시다면 아래와 같은 질문들에 대해 생각해보셔도 좋을 것 같아요! 제가 작성한 면접 질문입니다.

일반적인 질문

1. 함수형 프로그래밍이란 무엇인가요?
2. 자바스크립트에서 함수가 일급 객체인 것과 함수형 프로그래밍은 어떠한 관계가 있나요?
3. 자바스크립트는 왜 멀티 패러다임을 따른다고 할까요? 함수형 프로그래밍을 권장하는 것 아닌가요?

한단계 더 나아간 질문

1. (일반적인 질문 1번 문항에 이어) 그럼 순수 함수가 비순수 함수보다 좋은 것인가요?
2. (일반적인 질문 3번 문항에 이어) ECMAScript는 함수형 프로그래밍을 지향하는 방향으로 발전하고 있을까요?
3. (위의 2번 질문에 이어) Object.prototype.hasOwnProperty()와 같은 프로토타입 메서드가 있는데도, Object.hasOwn()와 같은 정적 메서드 대체제가 ECMAScript에 추가되는 이유가 무엇일까요? 함수형 프로그래밍과 관련이 있을까요? 그렇다면 그 이유를 말해주세요.
4. 함수형 프로그래밍은 선언적 프로그래밍과는 다른 것인가요?
5. (위의 4번 질문에 이어) 그럼 명령적 프로그래밍에 선언적 프로그래밍이 가지는 장점과 그 예시를 간단하게 들어줄 수 있나요?
6. 클로저와 함수형 프로그래밍은 어떤 관련이 있을까요?

리액트 관련

1. React 16.8 버전부터 Hook이 추가되면서 React 코드를 Class 문법이 아닌 함수형으로 작성하는 것이 주류가 되었는데, 그 이유를 함수형 프로그래밍 관점에서 설명해주실 수 있나요?
2. (위의 3번 문항에 이어 질문) 그럼 React 는 현재 함수형 프로그래밍을 지향하고 있는 것인가요?

[ssi02014]

codeisneverodd 의견 잘봤습니다. 좋은 말씀이시고 프론트엔드 관점으로 바라볼 때는 저도 간결함, 유지보수, 가독성이 중요한 것에 동의하는 바입니다 👍 저는 코테를 푸는 관점에서 시간복잡도를 어떻게 더 줄여 볼 수 있을까를 더 고민했던 것 같아요 🥲 그리고 저 또한, 리액트를 주력으로 하고 있고 함수형 프로그래밍을 지향하는만큼 좋은 피드백이 되었습니다.
공유해주신 면접 질문도 다시 한번 짚어보면서 놓친 부분 채워넣도록 하겠습니다 감사합니다 🙇‍♂️