삼색볼펜초학습법_변주첫번째 예전에 애자일 이야기 블로그에서 소개된 바쁜 직장인을 위한 스터디 비결을 읽고나서 회사에서 친구들과 삼색볼펜 초학습법을 약간 바꿔서 해봤다. 스터디 인원들이 저질야근, 저질 휴일근무(근무 시간을 초과한 업무시간은 무조건 저질)를 너무 많이 해서 시간 약속잡기 힘든 관계로 3개월만에 책 한권을 끝낼 수 있었다. 스터디 초반에는 늦잠으로 일관하던 주말 오전에 본사에 모여 했었고. 후반에는 평일 저녁 중 대부분이 약속없는 월요일에 모여했다.
<이색볼펜초학습법>
대강 진행방식은 이러하다. 같이 앉아서 책을 읽는 것이다. 책 한권이 여러개 챕터로 되어 있으니까 1챕터씩 시간을 정해 각자 조용히 읽는다. 읽으면서 핵심내용이라고 생각되는 부분을 빨강색으로, 핵심은 아니지만 중요하다고 생각되는 부분을 파랑색으로 치고 나서 시간이 끝나면 자기가 줄친 부분을 큰소리로 읽고 공유하는 공부방법이다.
기본적으로는 바쁜 직장인을 위한 스터디 비결에 근거해서 했지만 빨강색, 파랑색 볼펜 두가지 색만 사용했다는 점과 같은 챕터를 두번 읽지 않고 한번 읽을 때 빨간색, 파란색 줄을 같이 쳤다는 점을 바꿔서 해봤고, 빨간 줄 친 부분을 스터디위키에 올리는 것들을 절차에 추가했다.
인원 김정수. 원종인. 이호연. 정동인. 최지혜. 허진영
준비물 빨강색 파랑색 볼펜, Head First Object-Oriented Analysis & Design 한 권씩
1. 책을 들고 모인다. 먼저 절대 공부하고 오지 않는다. ------------------------------------------------------------------반복 2. 챕터별로 담당자를(위키에 빨간줄친 부분을 올릴 사람) 정한다. 3. 20분동안 한 챕터를 읽는다. (한 챕터는 대략 50 페이지) 3.1 중간에 모르는 것이 있으면 질문한다. 3.2 아는 사람이 대답해주고 확실치 않은 경우 넘어간다. 4. 20분 시간제한이 끝나면 각자 빨간 줄 친 부분을 큰 소리로 읽는다. 4.1 다시 처음 페이지부터 파란줄 친 부분을 읽는다. 4.2 챕터 담당자는 스터디원들이 빨간 줄 친 부분을 빼놓지 않고 체크한다. 5. 정리한다. 5.1 이건 모르겠는데 무엇이냐. 5.2 실제 업무에서 이런 거 쓴적 있냐. ------------------------------------------------------------------반복 6. 밥 또는 치킨을 먹는다. 7. 집에가서 스터디위키에 챕터별 담당자가 빨간줄 친 부분을 올린다. 8. 시간날 때 읽는다.(자유 선택)
<이슈>
1. 헤드퍼스트 시리즈 책이 내용 반복이 캐 많아서(앞 페이지에 나온 이야기가 옆에 굵은 글씨로 또 나오고, 그림으로도 보여주고, 챕터 맨 뒷장 핵심정리에 또 나오고) 빨간줄 치고 파란줄 친 것까지 모두 얘기하고 위키에 올리고 나니 빨간 줄 친 부분은 거의 외울 지경이었다. 물론 지금은 많이 까먹었지만 이 부분에서 큰 만족도를 얻었다. 헤드퍼스트와 삼색볼펜 초학습법의 시너지효과랄까.
또, 헤드퍼스트 시리즈가 같이 책읽기 스터디로 굉장히 좋은 교재라 생각되었던게 너무 두꺼워 과연 나혼자 다 읽을 수 있을까 같은 두려움 때문에 첫 장을 열기 어려운데 여러명이 같이 하기 때문에 다 읽는다는 사명감이 좀 더 있었다. 대게 읽는 동안 감정의 리듬을 따라가지 않는 전공 서적들은 혼자 완독하기가 힘들었는데, 좋아하지만 지긋지긋한(흐흐) 회사 동기들을 만난다는 즐거움과 사명감이 긍정적 영향을 주었던 것 같다.
2. 한 챕터를 읽는 20분 동안 노이즈가 대략 3분(?) 이상 발생하지 않았다. 발생하는 노이즈는 대략 내가 젤 많이 했던 책 읽던 중에 "그럼 Delegation을 구현한 코드는 어떤거야"와 같은 질문이었는데 책 읽는 도중 아는 사람이 이야기 해주었다. 다시 각자 책 읽기에 몰입하는데 크게 시간이 걸리지 않았다.
3. 이호연씨가 많이 했던 것인데 다 읽고 나서 다음 챕터로 넘어가기전에 그럼 우리가 읽은 것을 실제 업무에서 쓴 적이있는지 라던가 있다면 어떻게 어디서 사용했었는지 물어보며 정리했다. 예를들면 약정 프로그래밍과 방어적 프로그래밍에 대해서 이야기할 때 우린 대체적으로 방어적 프로그래밍(발생할 수 있는 모든 예외와 null값 반환을 처리하는 프로그래밍 : 고객이 어떤 테스트를 하더라도 안전한 반응을 얻을 수 있게하는 프로그래밍)을 해왔는데 그럼 고객의 동의아래 약정 프로그래밍을 해 본 사람이 있느냐. 해봤다면 어떻게 하였는지. 하는 것들이다.
4. 이 책을 보다 번역이 어색하다고 생각하는 부분에 대해서도 이야기를 했었다. 예를 들면 Client Class(객체, 메소드를 호출하는 클래스)를 고객 클래스라고 번역했던 것이라든지. Load 한다는 것을 적재한다고 했다던가. 등등등 무리없이 이해할 수 있는 것들이었지만 그래도 좀 더 나은 단어가 없을까에 대해서 이야기 해봤다.
5. 이슈라기보다 이것은 OOA&D 책을 읽고 개인적으로 알게 된 것. 유즈케이스 다이어그램, 시나리오 등등 소프트웨어 개발을 위해 사용되는 도구들은 많이 봤었지만 이것들을 언제 적시에 사용하는가에 대해서 궁금했었다. 또, 지금도 이미 다양한 도구가 있음에도 도구는 계속해서 새로 나오고 이 많은 도구들을 개발할때마다 꼭 다 사용해야 좋은 소프트웨어를 만들수 있는건지도 아리까리 했었다.
대략의 해답을 이 책에서 얻을 수 있었다. 결국 다다익선과 다경험이랄까;; 훌륭한 소프트웨어를 작성하는 효과적이고 성공적인 방법은 가능한 많은 도구를 갖고 있고 개발 주기의 각 단계에서 사용할 도구를 선택하는 것이다. 더 많은 도구를 가지고 있을수록, 문제를 살펴보고 처리할 더 많은 방법이 있다. 다음에 무엇을 해야할지 모르는 경우, 곤경에 빠졌을 때 어떤 도구를 선택해서 사용해보자. 좋은 해답을 얻을 기회가 있다.
<다음>
이 학습법에 만족도가 높았기 때문에 계속 진행하기로 했다. 시작은 했지만 다 읽지 못한 책들을 이야기해 본 결과 테스트 주도 개발이 나와서 다음은 이것으로 진행하기로 했다. 테스트 주도 개발 책은 헤드퍼스트 책과 다르게 코드를 써봐야하므로 아마도 삼색초학습법의 새로운 변주가 있을 듯 하다. :)최지
