팀 편성 알고리즘 part2

팀 편성 알고리즘

• 혼자 끙끙대다가 결국 코드를 갈아 엎고 다시 만들었다.
• 우선 너무 많은 상황을 가정하는 것이 문제였다. 엣지케이스 하나 때문에 정상적으로 돌아가는 로직이 안돌아가는 상황이었다.
• 그렇기 때문에 너무 많은 엣지케이스를 고려하지 않고, 심플하게 짜는 것을 목적으로 했다.
• 우선 기존의 방식이 서로가 선호하는 4인팀과 서로가 선호하는 2명을 먼저 나누고, 나머지 사람들을 여기에 넣는 방식이었기 때문에 고려해야 할 엣지케이스가 너무 많았다.
• 그렇기 때문에 바꾼 방식은
  1. 수강생 전원을 받아오고, 먼저 설문지를 제출한 사람부터 팀을 배정해서 나가는 FIFO(이런 말 쓰면 있어보이는것 같다.) 방식으로 변경했다. 설문지를 제출 하지 않은 사람들도 꽤 되다 보니, 먼저 제출한 사람들이 어느정도는 우선권을 가져가도 괜찮다는 생각이 들었다.
  2. 수강생의 이름을 넣으면, 선호하는 사람을 체크하고 같은 팀에 넣는다. 이 부분을 재귀로 돌려 1 > 2 > 3 > 4의 형태가 될 수 있게 했고, 이런 과정에서 4명이 서로 선호하는 (기존 팀을 유지하게 하는 경우) 케이스와 2명이 서로 맞는 경우를 처리 할 수 있었다.
  3. 재귀의 조건은 팀의 인원이 4명이 되면 리턴하는것이었기 때문에, 1번이 2번을 선호하고 2번이 3번을 선호 할 때, 1번이 3번을 싫어하지만 않는다면 같은 팀으로 배정했다. (1번이 선호하는 세명을 넣기에는 형평성의 문제가..)
  4. 그렇게 때문에 1번과 4번이 선호하고, 2번과 3번이 선호하더라도 서로가 싫어하지 않으면 문제가 되지는 않았다.
  5. 이렇게 편성될 때마다 팀 배열에 넣어서 끝!

이 된다면 정말 너무 좋겠지만, 뭐 코드가 항상 그렇듯이 내 맘대로 되는것은 아무것도 없었다.

1. 위의 방식대로 코드를 돌렸을 때, A라는 수강생의 이름을 넣으면 A가 포함될 수 있는 모든 조합이 나오는데, ex ) [A,B,C,D],[A,B,C,E] 여기에서 D와 E를 가를 수 있는 기준이 없었다.
2. 두번째로는 만약 설문을 제출하지 않은 수강생이 있는데, 그 수강생을 선호한다고 응답했을 경우 제출하지 않은 수강생을 수동으로 작성해줘야 했다. 엣지케이스를 처리하고 싶었지만.. 기수이동이라는 특성상, 어떤 수강생을 선호한다고 했을 때, 그 수강생이 기수이동을 하게 된다면 처리 할 수 있는 방법이 없었다.
3. 먼저 팀 배정이 된 수강생이 있는데, 나중에 코드를 돌린 수강생이 이 수강생을 선호한다고 할 경우 수동으로 처리해야했다.

급하게 회고 남기느라 대충 적기만 했는데도 문제점이 많은 알고리즘이다. 그래프 자료구조나 다른 자료구조들을 더 배웠다면 더 효율적으로(시간복잡도는 고려할 수도 없었다 ㅋㅋ) 짤 수 있지 않았을까 생각해본다. 이 태스크에만 집중하기에는 갑자기 너무 많은 태스크들이 몰려와서.. 당장 듀데잇을 맞추지는 못할 것 같다. 조금 여유로워지면.. 그때 다시 도전하는걸로! 우선은 여기에서 보류!