• 주단위로 책을 정리한다.

• 분량은 주당 책의 1장~2장 정도로 유동적으로 정한다.

• 한 주마다 리딩을 하는 사람 한명이 있고 그 외 멤버들은 책을 읽다가 모르는 점,

  기록으로 남겨 두고 싶은 예제 등 자유로운 방식으로 이슈를 추가한다.

• 스터디 시간 전까지 리딩하는 사람은 해당 이슈에 답변을 달고 스터디 시간에 함께 살펴본다.

  모두가 납득하면 close.

• 해결하지 못한 이슈는 stuck 처리한다.

책 스터디 그룹도 엄청 많고, 책 스터디의 방법론 또한 엄청 많다.

그렇기에 내가 생각한 방법을 설명하려고 한다.

사실 나는 개발자는 책을 많이 읽어야 한다는 말을 잘 몰랐다.

기존에는 그냥 "문제가 생기면 구글링을 해서 찾아야지" 라는 생각이었다.

하지만 이 말은 매우 위험 하다는걸 느꼈다.

애초에 무엇을 모르는지 모르는 상황에서 모르는 게 있으면 찾아본다는 점 자체가 문제가 있다.

요즘에는 개발자가 책을 읽는 이유를 말하라 하면 기존에 사용하던 기술을 좀 더 올바르게 사용할 수 있어서,

모르는 부분에 대한 키워드는 새롭게 알아볼 수 있는 트리거가 되어서라는 이유로 대답할 것이다.

우리 스터디가 지향하는 것은 "한 문장이라도 모르는 것을 대충 넘어가지 말자" 이런 지향점을 설정을 하고 싶다.

정말 코드 한 단락 가지고도 1시간 동안 토론 할 수 있는 등 책을 공격적으로 읽었으면 한다.

스터디는 일주일 단위로 사이클을 돌면서 이루어진다.

즉, 매주 스터디를 진행 하는데 그 해당 '주'의 리딩하는 사람은 매주 돌아가면서 한다는 얘기이다.

매주 (회의에서 협의) 모여서 책을 읽은 내용을 약 1~2시간 토론하는 시간을 가진다.

이때 주된 토론의 내용은, 책을 읽으면서 모르는 점에 대한 답변으로 이루어진다.

따라서 모든 스터디원이 책을 읽고 해당 분량에 대한 내용을 이해했다는 것을 전제로 한다.

(혹시 못하더라도 같이 이야기하면서 답을 찾는다)

issue의 기능은 간단하다 모르는 내용을 질문하는 게시판이다.

스터디 사이클에서 질문 & 답변에 해당하는 부분으로 이 부분이 핵심이다.

책을 읽으면서 궁금한 내용을 "한 문장이라도 모르는 것을 대충 넘어가지 말자" 라는 목표로 열심히 질문과 답변을 이어간다.

책을 읽으면서 애매한 부분에 대한 정리는 대부분 이 레포지토리에 정리가 되어있으며,

링크는 아래와 같다. https://github.com/mingseok/dev-book-review/issues

스터디 당일인 (회의에서 협의) 전까지 스터디원들은 책을 읽고 좀 더 세세하게 알고 싶은 내용이 있다면 github issue를 활용하여 질문을 남긴다.

해당 질문 내용을 그 주에 책을 리당하는 사람이 책임지고 답변을 달아둔다.

가끔 리딩하는 사람이 아니어도 해당 이슈에 대하여 관련된 내용을 오프라인으로 전달하며 개념을 확장해서 이야기할 수도 있다.

Reference
https://javabom.tistory.com/70