폭발 -o-

가능한한 구체적인 명세를 제공한다
more..
less..
명세가 중간에 바뀌면 누가 미리 시작하겠는가? 막판에 과제를 하면서 불거지는 "불확실한 명세로 인한 혼란"은 조교나 수강생 모두에게 원하지 않는 결과이다. 그러나 놀라운 것은, "명세는 언제나 애매하다"는 것이다!

이것은 놀라운 사실이다. 적지 않은 프로그래밍 과제가 "즉흥적"인 것이 아니라, 교과목의 내용과 수준을 고려하여 계획적으로 나오는 것을 생각하면, 매년 비슷한 과제에서 애매한 명세로 시행착오를 겪는 것은 신기한 일이다.

1) 명세을 정리해서 남기는 사람이 아무도 없기 때문에, 나중에 참고할 것이 없다.
2) 언제나 지난 자료를 그대로 활용하고, 수정 사항을 반영하는 데에는 별 관심이 없다.

2번은 명백한 잘못이다. 그러나 이러한 상황이 벌어진 것은, 대개 언제나 1번의 상황이기 때문이다. 어느 누구도 정확한 명세를 다음 번에 과제로 다시 낼 때까지 기억하지 않는다. (못한다!)

과연 "이외의 것은 상식에 준한다"라는 문구가 회피책이 될 수 있을까? 왜 보고서에서 채점 기준이 무엇이 될 것인지 알려주지 않는 것일까? 비급일까?

명세가 전달 된 이후에 수정하는 것은 신중히 이루어져야 한다. 보완을 위한 수정도 예외가 아니다.
more..
less..
명세를 변경하는 것은 결정권자에게는 "~~로 합니다"라는 멘트 하나로 끝날 수 있지만, 수강생들에게는 약한 파도 혹은 거대한 해일로 다가온다. 한두줄의 수정으로 가능한 경우도 있지만, 어떤 경우에는 설계를 다시해야 하는 경우도 있다!

혹자는 이런 경우를 대비해서 설계를 유연하게 해야한다고 할 수도 있다. 그러나 우리는 "현장의 프로젝트"를 수행하는 것이 아니라, "학부의 toy program"을 짜는 것이다. 제한된 시간 내에서 주어진 기능을 효과적으로 구현하기 위한 특화된 설계를 비난할수만은 없는 것 아닌가?

그런 만큼, 명세의 수정은 신중하게 이루어져야 한다. 가장 좋은 것은 더이상 구체적일 수 없는 명세이지만, 아쉽게도 그런 수준에 이르지 못했다면 수정이 불가피할 지도 모른다.

그러나 보완을 위한 수정, 즉 애매한 부분의 구체화 역시 신중하게 이루어져야 한다. 애매한 명세는 여러가지 구현을 낳는다. 이 책임은 분명 애매한 명세를 제공한 사람에게 있는 것이지, "과제를 성실히 수행하고 있는 자"에게 그 탓을 돌릴 수는 없는 법이다. 과제의 기능과 목적에서 크게 벗어나지 않는 다면, 자율에 맡기고 보고서에 명시하게 하는 것이 바람직하다. 채점이 번거로워질 수 있겠지만, 이는 애매한 명세의 업보이다.

명세의 수정은 구체적이어야 하고, 분명하게 전달되어야 한다.
more..
less..
명세의 수정 중에 가장 흔한 예는, 애매한 명세에 대한 누군가의 질문에 "그렇게 구현하십시오"라고 답글을 다는 경우이다. (구체화)
운좋게도 이런 글이 한두개 인 경우, 모두가 이 글을 보고 기억을 하고 있을 것이다. 그러나 애매한 명세와 수강생들의 끝없는 "정확한 명세에의 욕구"는, 수많은 질문과 이에 대한 수강생들의 해석과 논란, 그리고 조교의 답글로 승화한다. 게다가 별도의 시간에 질문을 받은 경우, 구두로 정한 것도 존재한다!

이러한 많은 명세의 수정은, 아무도 정리하지 않는다. 많은 학생들은 이 모든 것을 기억하고 있던가, 아니면 일일이 검색하는 성실함을 보여야 한다. 프로젝트의 목적은 요구사항의 실현일지언데, 그 가장 중요한 요구사항은 홀대받고 있는 것이다!

나는 주장한다. 명세를 완벽하게 만들기 위해 노력하는 것은 운명이기에, version을 관리해야 한다고 주장한다. 새로운 version이 나오면 마땅히 공지를 해야 한다. 그리고 이러한 작업은 마감일로 부터 얼마 남지 않은 기간에는 hold되어야 한다.

테스트셋은 상생의 정치다.
more..
less..
테스트셋을 요구하는 수강생에게, 조교의 가장 손쉬운 대답은 다음이다.
테스트셋을 제공하면 이에 특화된 프로그램을 만들기 때문에 안된다

일단 이 말은 한가지 오해를 담고 있고, 한가지 비웃음을 사게 한다.

오해는, 테스트셋은 요구사항을 충분히 만족시키는 지 체크하기 위한 것이다. 이 테스트셋을 모두 통과한다면, 요구사항을 만족시키는 것이고 이는 임무성공(과제로 말하면 만점)인 것이다.

혹시나, 그렇다면, "테스트셋으로 채점할 것을 가정하고, 이를 악용하여 가짜 ouput을 내는 프로그램을 작성할까 두려운 것"일까? 아니, 그렇다면 수강생들이 보내는 source코드 첨부한 이메일들은 다 휴지통으로 날아간단 말인가!

완벽한 테스트셋을 만들기란 거의 불가능하고 어렵다. 그러나 어쨌든 테스트셋을 제공한다면, 애매한 명세는 테스트셋 제작과정에서 줄어들 수 있을 것이다. (가장 좋은 것은 조교들이 먼저 과제를 한번 해보는 것이다!)

필요한 것만을, 정당하게 요구하자
more..
less..
수강생의 의문:
대체 소프트카피와 하드카피 두개를 요구하는 걸까? 식당에서 밥먹는 시간에도 보고서 채점을 하기 위해서일까? 이면지가 필요해서일까? 아니면.. 수업 없어도 한번 쯤 학교는 와보라는 걸까? (이래서 대신 내줄 친구를 사귀어놔야 하는 걸까?)
이메일 제목을 지켜야 하는 이유를 들어본 적보다는, 감점시키겠다는 반농담 반협박을 들어본 적이 더 많다. 혹시나 필터링되어서 날아가면 어떡하지? 그렇게 해서 한명 채점 덜하려고 그러는 걸까? 무섭다..

조교의 의문... 은 내가 해보지 않아서 잘 모르겠다 :)

간단하다. 무리한 부탁은 하지 않고, 필요하면 알아 들을 수 있게 설명하자.

점수에 민감한 것을 이해하자
more..
less..
"예고되지 않은 추가점수"... 당사자에게는 축복을, 나머지에게는 싸이오닉스톰을 내리는 말이다. 아니, 추가점수를 주겠다고 말도 하지 않은 부분에서 추가점수를 주는 것은, 점수에 휘둘리는 수강생들으로서는 암담한 상황이다. 불필요한 과제의 오버페이스는 결국 다른 것을 못하게 만든다. (공부?)
또, 기본 점수가 너무 높거나, 명세를 모두 채점하지 않는 것도 누군가는 상대적으로 손해를 보고 있는 셈이다. 누군가 조교를 열심히 욕하고 있을 지도 모른다. 다행인건, 대개 이름은 모르니, XX과목 조교로 호칭되는 것이다...