Younghoe.Info (final edition)

지도 교수님 권유로 학부 2학년을 대상으로 객체지향 프로그래밍 강의를 했다. 이제 두 번의 수업만 남았다. 새로운 경험이었고 여러 가지를 배웠다.

비현실적인 시간 강사 수입
소문을 들어 짐작은 했지만, 액수를 확인하니 '돈은 기대하지 않았다.'라는 생각이 100% 진실은 아님을 깨달았다. 회사나 프로젝트에 양해를 구해야 하는 탓에 우여곡절 끝에 한 학기는 맡았지만, 앞으로 다시 하기는 어려울 듯하다.

수동적인 수업 분위기
08학번이면 10년도 더 차이 나는 친구들이다. 강산은 변했지만, 수업을 받는 태도는 그대로다. 처음엔 분위기를 꽤 고무적으로 유지했다. 하지만, 오랜 습성은 쉬이 바뀌지 않았다. 시험을 통해 확인해보니 역시 일방적인 교육의 효과는 높지 않았다. 그래서, 중간고사 이후에는 발표 위주로 양방향 교육을 시도했다. 애초부터 계획한 내용이 아닌 터라 강의 진행이 좀 어수선했지만, 효과는 기대보다 좋았다.

폼 나는 주제
물론, 첫 발표 시간은 기대 이하였다. 실망한 이유는 아이들의 주제 선정 탓이다. 고작 지난 학기에 프로그래밍 언어 문법을 배우고, 이번 학기 비로소 객체, 클래스나 상속 개념을 익힌 친구들이다. 그런데 대부분 화려한 UI로 무장한 프로그램이나 보드 게임 등을 주제로 들고 나다. 일단, 시행착오 역시 배우는 과정이라 믿고 그대로 두었다. 단지 첫 발표를 마칠 즈음에 수업 초점에 대해서 덧붙여줬다. 클래스를 정의하고 균형감 있게 조직화하는 과정을 배우는 것 이외에는 모두 수업 범위 밖이라고 강조했다. 덧붙여서 (수업 시간에 배운) TDD를 통해 주어진 시간을 영리하게 쓰는 방법을 익히라고 했다.

진화 혹은 자가 개선
두 번째 시간에 효과를 확인했다. Swing을 익혀가면서 과제를 진행하던 친구가 일주일 만에 '일이 너무 커져서 수업 이후 면담을 요청한다.'라고 발표했다. 반가운 소식이었다. 공유할만한 내용인 탓에 수업 중에 모두를 향해 답해주었다. 그 친구가 정한 주제는 '소모임 정산 프로그램'이었다. 무리를 이루어 다니면서 쓰는 돈을 공평하게 정산하여 분쟁을 없애겠다는 깜찍한 발상을 실현할 프로그램이다. UI부터 작업하다 보니 수업시간에는 다루지도 않은 Swing을 써서 UI 컴포넌트를 배열하느라 고전하고 있었다. UI보다는 그 친구가 개념으로 포착한 '자원', '지출', '정산' 등을 클래스로 정의하고 역할에 맞춰서 적절하게 코드를 분배하고 효과적으로 호출하는데 초점을 맞춰보라고 충고했다. UI 버튼이 만들어내는 이벤트는 테스트 메소드 안에서 코드로 대신할 수 있다고 예를 들어서 알려주었다.

용어 남용 자제하다 얻은 보너스
다음에 발표한 학생이 작성한 코드는 더욱 구체적인 조언을 할 수 있는 기회를 주었다. testCreate() 라는 이름의 테스트 메소드 안에 최초로 작성한 두 개 클래스에 대한 테스트를 모두 담고 있었다. 이 코드에서 개선할 사항이 있느냐고 물었다. 어떻게 설명을 하면 좋을까?


만일 이제 갓 프로그래밍을 배우는 학생이 아니라 리팩터링 정도는 아는 사람을 대상으로 했다면 아마도 긴 메소드(Long Method)의 냄새가 난다고 설명했을지도 모른다. 혹은 단일책임원칙(Single Responsibility Principle)은 테스트 메소드에 대해서도 유효하다고 간편하게 설명했으려나?

배경지식이 없는 학생에게 이해할 수 있게 설명해 보려는 시도는 '이미 안다고 느꼈던 내용'에 대해 '다른 시각'으로 볼 기회를 주었다. 내 설명은 대략이랬다. 솔직히 나도 즉석에서 한 답변이라 상세한 내용은 기억 못 한다. 

"이 정도 분량이라면 심하게 부담스럽지는 않지만, 만일 코드가 매우 많다고 생각을 해보자. testCreate() 메소드 안을 보면 사용자가 입력한 데이터를 표현하는 PhoneBook 객체를 생성하는 코드(1)가 있다. 또, PhoneBook을 관리하는 PhoneBookManager 객체에 추가(2)하는 코드도 있다. 거기에 더하여 특정 값을 이용하여 다시 객체를 꺼내는 코드(3)도 있다. 코드를 작성하고 시간이 흘렀는데, 어느 날 갑자기 셋 중 일부를 고쳐야 했다.

작성하고 얼마 지나지 않았다면 금세 찾겠지만, 남이 작성한 코드이거나 자기가 작성했어도 긴 시간이 흘렀다면 찾기가 쉽지 않을 수 있다. 한 번 고생하고 나서 훗날을 위해 코드 바로 위에 친절하게 주석을 달아줄 수 있다. 그렇다고 해도 전체 코드를 훑어봐야 하는 점은 바뀌지 않는다. 그런데 만일 testCreate() 외에 다른 기능을 테스트하는 코드를 각기 testAddPhoneNumber()와 testFindByNumber() 로 구분하면 어떨까? 아무리 코드가 길어도 스크롤 할 필요 없이 이클립스에서 Ctrl+O 키를 눌러서 단박에 찾을 수 있다."

상당수 학생이 교감하는 눈치였다.

또 코드를 보면 기계적으로 ~Manager로 CRUD를 하려는 부분이 보였다. 전화번호가 아니라 전화번호부를 관리하는 프로그램을 짜려고 하는 것은 아닌 것으로 보인다고 확인해주었다. 가능하면 익숙한 개념을 빌어와야 균형 있는 클래스의 상호작용을 기대할 수 있다고 말해주었다. 이런 설명을 하는 와중에 스치고 지나간 생각이 있었다.

써니님의 글을 읽다가... 생각나서
원저자인 Grady님의 허락을 구해 올립니다.

출처: 'Grady의 골 때리는 디자인 패턴' 중에서

호응이 있으면 MMORPG와 엮어서 디자인 패턴을 어디에 써야 하는지 짧은 글로 명쾌하게 설명한 'Grady의 골 때리는 디자인 패턴' 을 제 블로그에 연재하도록 하겠습니다.

습관적으로 만드는 Top-down 분류 코드를 보고, 거부감이 들었다. 객체지향 초기에 스스로 품고 있었던 악습이 다른 사람의 코드를 통해 재현했기 때문인 듯하다. 깜빡 있고 있었는데, 좋은 그림이 있어서 다시 떠올랐다.



JDK와 같이 이미 널리 쓰는 라이브러리안에 혹은 동료들이 이미 작성한 코드에서 가져다 쓸 클래스가 있는데도 무언가 새로 정의할 때!

새로운 클래스는 복잡도라는 이름으로 불리울 수 있다. 레거시가 있는데 새로 무언가 만든다는 것은 중복을 낳는 것이고, 이는 갈림길을 만들어 후일 두 부류의 코드를 양산한다. 그런 것이 쌓이고 쌓이면 복잡도가 가중된다. 나는 동료가 혹은 스스로가 이미 있는 것 외에 새로운 무언가를 만들고자 할 때, 혹은 상속을 통해 확장 계층을 만들 때 다음과 같은 질문을 할 것이다:


대가만 충분하다면야... 복잡도는 확장성(예:프레임워크) 내지는 혁신(예:AOP) 등으로 변모할 수 있으니까.

그림 출처: 과도한 추상화