Difference between r1.2 and the current
@@ -1,37 +1,62 @@
~~멍청하게 혼자 기획한 부회장과 그를 까기 위한 급조된 TF(라 읽고 거지같은 동기들이라 부른다)들의 모임~~
= 입출력 방식이 제각각인 것에 대한 대처 =
* 부회장: 문제에서 정해진 입출력이 아닌 입출력에 대해서는 채점 프로그램을 돌리는 것도 아니라서 빡빡하게 안하려고 생각했음.
* TF: 명확한 기준이 아니라서 용인은 해줬지만 채점할 때, 죄다 다르게 나와서 눈으로 일일이 확인해야 해서 골치 아팠음.
* TF: 부회장이 우리에게 테스트 케이스 만들어오는 것을 시켰더라도, 그게 진짜 맞는 지는 부회장이 한 번 확인해봤어야 했다. 그리고 만들 때, 부회장이 적어도 빠르게 테스트 케이스가 맞는지 확인할 수 있는 수단이 있는 줄 알았다.
* 결론: TF에게 테스트 케이스를 맡길 때는 TF에게 검증까지 해야하는 지도 알려주고, TF도 검증이 필요한 테스트 케이스는 미리 넘겨줘야 한다.
= 테스트 자동화 -> 출력 형식이 엄격해야한다 =
* 주최자가 대회를 등수를 나누는 데 의도가 있다면, 그만큼 테스트 자동화와 엄격한 출력 형식, 많은 테스트 케이스는 필수다. 하지만 애초에 대회 의도가 같이 코딩해서 서로 부족한 점을 찾는 기회가 되는 게 목표였다면 테스트 자동화까지 구현해놓는 것은 부차적으로 고려해야 하는 것이라고 결론남.
= 이런 의도를 TF가 확실히 공유 받고 참가자에게 전달해야함 =
* 사전 교육이 중요함. 주최자가 생각하는 진행 방식을 TF가 미리 알고 있어야 함.
= 제출 방식 -> 이번 방식은 위키에 올렸는데, 좀 문제가 있음 =
= TF 적절한 수로 해야됨 =
= 문제의 난이도 =
* 문제의 난이도 조절을 위해서 처음에는 튜터들을 출제자로 두고 튜티들만 대회에 참가하는 방향으로 바꾸자는 제의가 들어왔다
* 하지만 대회 의도가 튜터와 튜티가 서로 협력하면서 튜티에게 잘 하는 사람의 코드를 배우게 하는 게 의도라면 튜터도 참가자로 같이 있어야 한다.
* 여담이지만 이번 문제지의 가독성이 너무 부족했다.(부회장은 분명 베타테스트를 세번이나 돌렸는데 왜 다들 그 때는 말 안하고 대회 시작하고 나서야 이거 가독성 떨어지네라고 말하지... ㅠㅠㅠ)
= 비공개된 테스트 =
* 참가자들이 제출할 답안을 위키에 올린 다음, TF가 위키에서 제출 답안을 받게 했는데 공개된 곳에 올리면 문제가 있다고 판단함. (실제로는 부정행위 문제는 안 생겼지만...)
1. 제출 시간을 기록할 수 있을 것
2. 다른 팀이 볼 수 없어야 함, 수정도 불가
= 결론 =
* 문제가 코드가 길어지고 어려울수록 대회 전에 TF 많이 뽑아서 기획해야함... 그렇지 않으면 위의 문제가 발생할 수 있음. 그리고 언제나 대회의 의도는 모두가 미리 공유하고 있어야 함.
-------------------------------------------------------------------------------------------------------------------
[CodeRace] [CodeRace/2016]
아 몰랑 다들 그냥 숯부래나 가서 고기나 구워먹자!!!
[[TableOfContents]]= 입출력 방식이 제각각인 것에 대한 대처 =
* 부회장: 문제에서 정해진 입출력이 아닌 입출력에 대해서는 채점 프로그램을 돌리는 것도 아니라서 빡빡하게 안하려고 생각했음.
* TF: 명확한 기준이 아니라서 용인은 해줬지만 채점할 때, 죄다 다르게 나와서 눈으로 일일이 확인해야 해서 골치 아팠음.
= 출제자는 문제 상황에서 정확하게 동작하는 샘플 Program을 만들어야 한다 =
= 정답을 내놓는 샘플 Program을 미리 만들어야 한다 =
* 부회장: 나중에도 말하겠지만, 손으로 검증할 수 있는 수준의 문제라고 생각해서 설마 준비한 테스트 케이스가 틀렸을 거란 걸 생각도 못한... * TF: 문제 출제자도 아니라서 문제에 대한 이해가 부족했고, 그 때문에 잘못된 테스트 케이스가 나온 것은 잘못으로 인정함. 그래도 부회장이 사전에 샘플 프로그램도 만들어 뒀으면 TF가 테스트 케이스 준비에 편했을 것이라고 생각함.
= 다른 사람에게 test case 제작을 맡기고 돌려서 검증 =
* TF: 문제에 대한 이해가 부족했고, 그 때문에 잘못된 테스트 케이스가 나온 것은 잘못으로 인정함. 그래도 부회장이 사전에 샘플 프로그램도 만들어 뒀으면 TF가 테스트 케이스 준비에 편했을 것이라고 생각함.
= TF에게 test case 제작을 맡기고 돌려서 검증을 했어야 했다 =
* 부회장: 나는 테스트 케이스를 만들어보라고 요청했던 TF가 전부 내가 그 전에 문제 검증을 부탁했던 TF였다. 그래서 문제에 대한 이해도는 있을 줄 알았고, 각자가 만든 테스트 케이스는 각자 들고 다니면서 채점 용도로 쓸 거라고 말해줘서 자기가 사용할 테스트 케이스니까 정확한 테스트 케이스를 만들 것이라고 생각하고 테스트 케이스 제작을 부탁했다. 그리고 TF로부터 불완전한 테스트 케이스를 받았는데 검증할 수 있는 시간이 부족했다.* TF: 부회장이 우리에게 테스트 케이스 만들어오는 것을 시켰더라도, 그게 진짜 맞는 지는 부회장이 한 번 확인해봤어야 했다. 그리고 만들 때, 부회장이 적어도 빠르게 테스트 케이스가 맞는지 확인할 수 있는 수단이 있는 줄 알았다.
* 결론: TF에게 테스트 케이스를 맡길 때는 TF에게 검증까지 해야하는 지도 알려주고, TF도 검증이 필요한 테스트 케이스는 미리 넘겨줘야 한다.
* 주최자가 대회를 등수를 나누는 데 의도가 있다면, 그만큼 테스트 자동화와 엄격한 출력 형식, 많은 테스트 케이스는 필수다. 하지만 애초에 대회 의도가 같이 코딩해서 서로 부족한 점을 찾는 기회가 되는 게 목표였다면 테스트 자동화까지 구현해놓는 것은 부차적으로 고려해야 하는 것이라고 결론남.
= 출제자의 의도를 분명히 사전에 전달 =
* 출제자가 타임 어택을
= 주최자의 의도를 분명히 사전에 전달 =
* 주최자가 타임 어택을 의도했다면 TF도 엄격하게 검사를 함.
* 주최자가 느슨하게 진행할 의도였다면 TF도 느슨하게 함.
* 주최자의 의도가 클린 코드가 목적이었다면, TF가 좋은 코드를 짰는지 확인을 해야 함.
* 이러한 의도를 전달해야 TF도 최소한 그에 맞게 행동함. 그리고 이런 의도를 미리 말하면 TF가 미리 이런 경우엔 어떻게 하냐고 물어볼 수도 있고, 의견을 제시할 수도 있다. 그렇게 하면 미리 대회 때 발생할 수 있는 문제를 제거할 수 있다.
* 사전 교육이 중요함. 주최자가 생각하는 진행 방식을 TF가 미리 알고 있어야 함.
* TF가 너무 부족했음. 특히 채점이 자동화가 아니라면 그만큼 TF 수는 많아야 함. (TF 5명이서 개고생함)
* 문제의 난이도 조절을 위해서 처음에는 튜터들을 출제자로 두고 튜티들만 대회에 참가하는 방향으로 바꾸자는 제의가 들어왔다
* 하지만 대회 의도가 튜터와 튜티가 서로 협력하면서 튜티에게 잘 하는 사람의 코드를 배우게 하는 게 의도라면 튜터도 참가자로 같이 있어야 한다.
* 여담이지만 이번 문제지의 가독성이 너무 부족했다.(부회장은 분명 베타테스트를 세번이나 돌렸는데 왜 다들 그 때는 말 안하고 대회 시작하고 나서야 이거 가독성 떨어지네라고 말하지... ㅠㅠㅠ)
= 튜터는 어느정도까지 관여 =
* 그리고 만약 문제가 이번년도 같은 스타일이 아닌 예년같은 스타일이면 테스트 케이스도 많지 않고 정답인지 확인하기도 쉽다. 그러니 테스트 자동화와 TF 수는 문제 스타일에 따라 재고해봐야함.
= 튜터는 어느정도까지 관여해야 하나 =
* 처음에는 튜티들의 공평한 경쟁을 위해서 튜터가 최대한 관여를 안하는게 낫다고 생각했는데, 이번 대회의 의도는 서로 협력하는 게 의도였기 때문에 튜터의 지시에 제한을 거는 것은 문제가 있다고 판단함. *
* 그렇다고 튜터가 구현에 대한 생각을 다 하면, 튜티는 코드 짜는 기계가 되는 게 아니냐는 말이 나옴.
* 대회 목적이 튜터같은 실력자가 구현을 하는 방법을 튜티가 배우는 게 목적이라면, 튜티에게 그런 걸 가르칠 수 있는, 기계적으로 남의 코드를 짜게 하는게 아니고 코드의 의미를 알게 할 수 있어야 함.
* 그래서 튜터가 구현을 말을 하고 튜티가 코드를 짜게 하되, (11번 항목에서 설명할) 코드 띄우고 투표하는 시간에, 튜티가 나가서 그 코드의 역할과 이렇게 짠 의도 등을 발표하는 시간을 갖게 하면, 튜터가 튜티에게 코딩을 강제했는지 아니면 튜티가 이해할 수 있는 수준을 설명했는지 알 수 있다는 아이디어가 나옴.
* 참가자들이 제출할 답안을 위키에 올린 다음, TF가 위키에서 제출 답안을 받게 했는데 공개된 곳에 올리면 문제가 있다고 판단함. (실제로는 부정행위 문제는 안 생겼지만...)
* 비공개된 테스트가 필요함. gist를 쓰자는 의견도 있긴 한데 결론적으로 비공개된 테스트 방법은 두 가지 조건이 만족되어야 한다.
* 비공개된 테스트가 필요함. gist를 쓰자는 의견도 있긴 한데 결론적으로 비공개된 테스트 방법은 세 가지 조건이 만족되어야 한다.
1. 제출 시간을 기록할 수 있을 것
2. 다른 팀이 볼 수 없어야 함, 수정도 불가
3. TF가 코드 긁어오기 쉬워야 함.
= 주최자의 의도는 가르치는 거였는데 실제론 그걸 못함 =
* 주최자의 의도는 있었는데 그걸 제대로 이끌어내질 못함. 이건 주최자가 너무 대충 생각함(부회장: 죄송합니다 ㅠㅠ)
* 주최자가 배경지식에 대해 충분히 설명을 못함. (부회장의 변명: 너무 시작부터 사람들의 집중력이 떨어졌음. 특히 강단이 앞에 있는 장소에서 할거면 사람들이 앞을 바라보게 앉혀야 함. 그렇지 않으면 다 등 돌리고 자기 할 거 하고 있음. 참가자들이 앞을 보고 앉도록 TF에게 미리 시켰어야 했음)
* 주최자는 또한 클린 코드에 대한 경험을 주고 싶었는데 대회 진행이 타임어택만 있었음. (변명: 타임어택이 가장 공평하게 평가할 수 있었고, 문제의 질을 따지는 것은 사람마다 제각각이라서 하기가 어렵다고 판단함.)
* 만약 굳이 클린 코드를 의도로 해서 대회를 진행한다면, 다음 대회에서는 타임어택을 빼고, 제한된 시간 안에 코드를 완성해서 각자의 코드를 띄워두고 다른 팀보고 잘 짠 코드인지 투표하게 해서 가장 많은 좋아요(?)를 획득한 팀을 우승으로 하게 하자는 아이디어가 나왔음. 다음 회장단은 참고.
* 문제가 코드가 길어지고 어려울수록 대회 전에 TF 많이 뽑아서 기획해야함... 그렇지 않으면 위의 문제가 발생할 수 있음. 그리고 언제나 대회의 의도는 모두가 미리 공유하고 있어야 함.
* 제발 행사 좀 도와줘... 왜 다들 바쁘다고 TF 해줄 수 있냐고 물어보면 도와주질 않냐...
[CodeRace] [CodeRace/2016]
1. 입출력 방식이 제각각인 것에 대한 대처 ¶
- 부회장: 문제에서 정해진 입출력이 아닌 입출력에 대해서는 채점 프로그램을 돌리는 것도 아니라서 빡빡하게 안하려고 생각했음.
- TF: 명확한 기준이 아니라서 용인은 해줬지만 채점할 때, 죄다 다르게 나와서 눈으로 일일이 확인해야 해서 골치 아팠음.
2. 정답을 내놓는 샘플 Program을 미리 만들어야 한다 ¶
- 부회장: 나중에도 말하겠지만, 손으로 검증할 수 있는 수준의 문제라고 생각해서 설마 준비한 테스트 케이스가 틀렸을 거란 걸 생각도 못한...
- TF: 문제에 대한 이해가 부족했고, 그 때문에 잘못된 테스트 케이스가 나온 것은 잘못으로 인정함. 그래도 부회장이 사전에 샘플 프로그램도 만들어 뒀으면 TF가 테스트 케이스 준비에 편했을 것이라고 생각함.
3. TF에게 test case 제작을 맡기고 돌려서 검증을 했어야 했다 ¶
- 부회장: 나는 테스트 케이스를 만들어보라고 요청했던 TF가 전부 내가 그 전에 문제 검증을 부탁했던 TF였다. 그래서 문제에 대한 이해도는 있을 줄 알았고, 각자가 만든 테스트 케이스는 각자 들고 다니면서 채점 용도로 쓸 거라고 말해줘서 자기가 사용할 테스트 케이스니까 정확한 테스트 케이스를 만들 것이라고 생각하고 테스트 케이스 제작을 부탁했다. 그리고 TF로부터 불완전한 테스트 케이스를 받았는데 검증할 수 있는 시간이 부족했다.
- TF: 부회장이 우리에게 테스트 케이스 만들어오는 것을 시켰더라도, 그게 진짜 맞는 지는 부회장이 한 번 확인해봤어야 했다. 그리고 만들 때, 부회장이 적어도 빠르게 테스트 케이스가 맞는지 확인할 수 있는 수단이 있는 줄 알았다.
- 결론: TF에게 테스트 케이스를 맡길 때는 TF에게 검증까지 해야하는 지도 알려주고, TF도 검증이 필요한 테스트 케이스는 미리 넘겨줘야 한다.
4. 테스트 자동화 -> 출력 형식이 엄격해야한다 ¶
- 주최자가 대회를 등수를 나누는 데 의도가 있다면, 그만큼 테스트 자동화와 엄격한 출력 형식, 많은 테스트 케이스는 필수다. 하지만 애초에 대회 의도가 같이 코딩해서 서로 부족한 점을 찾는 기회가 되는 게 목표였다면 테스트 자동화까지 구현해놓는 것은 부차적으로 고려해야 하는 것이라고 결론남.
5. 주최자의 의도를 분명히 사전에 전달 ¶
- 주최자가 타임 어택을 의도했다면 TF도 엄격하게 검사를 함.
- 주최자가 느슨하게 진행할 의도였다면 TF도 느슨하게 함.
- 주최자의 의도가 클린 코드가 목적이었다면, TF가 좋은 코드를 짰는지 확인을 해야 함.
- 이러한 의도를 전달해야 TF도 최소한 그에 맞게 행동함. 그리고 이런 의도를 미리 말하면 TF가 미리 이런 경우엔 어떻게 하냐고 물어볼 수도 있고, 의견을 제시할 수도 있다. 그렇게 하면 미리 대회 때 발생할 수 있는 문제를 제거할 수 있다.
8. 문제의 난이도 ¶
- 문제의 난이도 조절을 위해서 처음에는 튜터들을 출제자로 두고 튜티들만 대회에 참가하는 방향으로 바꾸자는 제의가 들어왔다
- 하지만 대회 의도가 튜터와 튜티가 서로 협력하면서 튜티에게 잘 하는 사람의 코드를 배우게 하는 게 의도라면 튜터도 참가자로 같이 있어야 한다.
- 여담이지만 이번 문제지의 가독성이 너무 부족했다.(부회장은 분명 베타테스트를 세번이나 돌렸는데 왜 다들 그 때는 말 안하고 대회 시작하고 나서야 이거 가독성 떨어지네라고 말하지... ㅠㅠㅠ)
- 그리고 만약 문제가 이번년도 같은 스타일이 아닌 예년같은 스타일이면 테스트 케이스도 많지 않고 정답인지 확인하기도 쉽다. 그러니 테스트 자동화와 TF 수는 문제 스타일에 따라 재고해봐야함.
9. 튜터는 어느정도까지 관여해야 하나 ¶
- 처음에는 튜티들의 공평한 경쟁을 위해서 튜터가 최대한 관여를 안하는게 낫다고 생각했는데, 이번 대회의 의도는 서로 협력하는 게 의도였기 때문에 튜터의 지시에 제한을 거는 것은 문제가 있다고 판단함.
- 그렇다고 튜터가 구현에 대한 생각을 다 하면, 튜티는 코드 짜는 기계가 되는 게 아니냐는 말이 나옴.
- 대회 목적이 튜터같은 실력자가 구현을 하는 방법을 튜티가 배우는 게 목적이라면, 튜티에게 그런 걸 가르칠 수 있는, 기계적으로 남의 코드를 짜게 하는게 아니고 코드의 의미를 알게 할 수 있어야 함.
- 그래서 튜터가 구현을 말을 하고 튜티가 코드를 짜게 하되, (11번 항목에서 설명할) 코드 띄우고 투표하는 시간에, 튜티가 나가서 그 코드의 역할과 이렇게 짠 의도 등을 발표하는 시간을 갖게 하면, 튜터가 튜티에게 코딩을 강제했는지 아니면 튜티가 이해할 수 있는 수준을 설명했는지 알 수 있다는 아이디어가 나옴.
10. 비공개된 테스트 ¶
- 참가자들이 제출할 답안을 위키에 올린 다음, TF가 위키에서 제출 답안을 받게 했는데 공개된 곳에 올리면 문제가 있다고 판단함. (실제로는 부정행위 문제는 안 생겼지만...)
- 비공개된 테스트가 필요함. gist를 쓰자는 의견도 있긴 한데 결론적으로 비공개된 테스트 방법은 세 가지 조건이 만족되어야 한다.
- 제출 시간을 기록할 수 있을 것
- 다른 팀이 볼 수 없어야 함, 수정도 불가
- TF가 코드 긁어오기 쉬워야 함.
- 제출 시간을 기록할 수 있을 것
11. 주최자의 의도는 가르치는 거였는데 실제론 그걸 못함 ¶
- 주최자의 의도는 있었는데 그걸 제대로 이끌어내질 못함. 이건 주최자가 너무 대충 생각함(부회장: 죄송합니다 ㅠㅠ)
- 주최자가 배경지식에 대해 충분히 설명을 못함. (부회장의 변명: 너무 시작부터 사람들의 집중력이 떨어졌음. 특히 강단이 앞에 있는 장소에서 할거면 사람들이 앞을 바라보게 앉혀야 함. 그렇지 않으면 다 등 돌리고 자기 할 거 하고 있음. 참가자들이 앞을 보고 앉도록 TF에게 미리 시켰어야 했음)
- 주최자는 또한 클린 코드에 대한 경험을 주고 싶었는데 대회 진행이 타임어택만 있었음. (변명: 타임어택이 가장 공평하게 평가할 수 있었고, 문제의 질을 따지는 것은 사람마다 제각각이라서 하기가 어렵다고 판단함.)
- 만약 굳이 클린 코드를 의도로 해서 대회를 진행한다면, 다음 대회에서는 타임어택을 빼고, 제한된 시간 안에 코드를 완성해서 각자의 코드를 띄워두고 다른 팀보고 잘 짠 코드인지 투표하게 해서 가장 많은 좋아요(?)를 획득한 팀을 우승으로 하게 하자는 아이디어가 나왔음. 다음 회장단은 참고.
