구현하면서 느낀 비효율성

이렇게 구성하는 것은 너무 비효율적인 것 같다.

• 모집 분야는 여러개가 될 수 있다.
• 기술 스택도 여러개가 될 수 있다.

그렇다는 것은 해당 정보들을 받아올 때, 아래와 같은 상황이 발생한다는 것이다.

• 만약 요구되는 기술 스택이 많을 경우, 요구 능력치 설정이 과하게 느껴질 것 같다.
  • 개발자의 경우, 요구되는 스택 수가 엄청나게 늘어날 수 있는데 그걸 다 체크하기엔 번거롭고, 보는 입장에서도 별로일 것 같다.
• 모집분야가 여러개 있다 → 모집 분야에 따른 기술 스택도 여러개 있다. → 프론트에서 정보를 JSON으로 파싱해서 줄 때, 적어도 이중 Map 형태로 줘야한다는 문제가 발생한다.

이렇게까지 비효율적이고, 번거롭게 처리해야만 할까? 아니라고 생각한다. 다른 방법을 생각해보기로 했다.

생각 ON!

• 모집 분야는 디폴트로 내걸자.
  • 이 말인 즉슨, 모집 분야인 디자인, 프론트, 백엔드를 디폴트 값으로 노출시키겠다는 의미이다.
  • 모든 모집 글은 디자인/프론트엔드/백엔드 영역에 해당하는 기술 스택 필드를 가진다.
• 그리고 간과했던 게 있는데, 모집 인원을 전체 인원에서 각 분야 별 인원으로 수정하기로 했다.
• 그리고 스택 별로 요구됐던 능력치를 종합 요구 능력치로 변경한다. 이에 대해서는 섬세한 기준이 필요할 것이다.

ERD 재설계

위의 ERD는 과감하게 지웠다. 그리고 다시 설계하였다. 틀린 부분이 있다면 과감하게 지우는 게 미련도 안남고, 생각을 리프레시 하기 좋은 것 같다. (만약 지워선 안되는 부분이 있다면 지우면 안되겠지만.. 완전 실패한 설계는 과감히 지우는게 낫다고 생각한다.)

ERD를 위와 같이 구성하기로 했다. 구성한 대로 Entity를 다시 구현해보자

Entity 재구현