오브젝트 독서회 1회차
Intro
오브젝트 독서회 1회차를 진행했습니다.
강남역 부근의 윙스터디에서 6인실을 대여하여 진행했으며 인당 시간당 2,200원씩 하여 22,000원으로 선결제 예약 후 이용했습니다.
스페이스 클라우드 라는 서비스를 통해 예약했는데, 사진과 많이 달랐던 점이 아쉬웠습니다.
하지만 스터디를 진행하는데 큰 불편함은 없었고 강남역 부근에서 그만한 가격으로 스터디 장소를 예약하기는 힘들기 때문에 추천드립니다.
오프라인에서 처음 만나는 자리였기에 간단히 자기소개와 아이스브레이킹을 20분 정도 했습니다.
이후 20시까지 이번 분량이었던 오브젝트 0, 1 챕터를 시작했습니다.
코드가 포함된 추상화 안내서를 30~60분 이내에 읽고 정리까지 하는 것은 무리라고 생각했기 때문에 사전에 오브젝트 책의 챕터별로 페이지 수를 계산하여, 챕터를 1개씩 진행하는 것으로 정하고 구성원들에게 사전에 읽어오라고 알려드렸습니다.
그래서 20시가 되면, 각자 인상 깊었던 책의 문구를 마킹해서 개인 독후감 발표 시간에 발표하는 것이었습니다.
우선 가이드라인으로 1인당 10분씩 5~10개 정도의 문장을 정리해달라고 알려드렸습니다.
아무래도 다들 스터디를 하는 입장이라 초보이기 때문에 관점이 비슷해서 그런지 정리된 문장들이 비슷했습니다.
어쩌면 책의 대부분의 구절들이 도움이 되는 문장으로만 구성되어 있기 때문인 것 같기도 합니다.
아래 나열된 순서대로 개인 독후감을 진행했고, 제가 첫번째로 발표했기 떄문에 공유할 것을 모두 공유하는 바람에 시간을 10분을 살짝 넘겨서 사용했습니다.
이후에 발표하시는 콘트리트장인님, muki님, 아메리카노님, freebear님은 저와 겹치는 부분은 제외하고 발표해주셔서 시간이 조금씩 남으셨습니다.
뭔가 다들 공유해주시고 싶은 말씀이 많으셨을텐데 제가 다 해버려서 못하신 것 같아 아쉬움이 있었습니다.
다음 회차에는 나누고 싶은 문장은 같을 수 있지만, 경험은 개인의 것이니 문장이 같더라도 느끼신 경험 나눠주시면 좋겠다고 생각했습니다.
freebear님께서 마지막 발표 후, 혹시라도 더 나누고 싶었던 문장이나, 경험이 있었다면 공유해달라고 요청드렸고, 다들 남는 시간을 잘 참여해주셔서 시간을 알뜰하게 사용할 수 있었습니다.
이후 지금 정리된 회고를 프로토타이핑 한 것을 공유하고 피드백 받기 위해 카카오톡 오픈채팅방을 만들었습니다.
오픈 채팅방은 책 1권의 독서회 당 유지하는 것으로 하여, 어떤 인맥의 목적으로 사용되지 않고 독서회가 종료되면 그 즉시 방을 해체할 수 있게 정책을 정했습니다.
독서회를 참여해주시는 분들이 책의 내용 뿐 아니라 개발 서적으로 그룹 스터디를 어떻게 진행하는지 다함께 훈련하고 그 레퍼런스는 포럼을 통해 공유하면 되기를 원했기 때문입니다.
이후에라도 얼마든지 포럼의 채팅방이나 연락처를 통해 연락할 수 있으므로 방의 목적은 오로지 독서회를 위해서만 존재하는 것으로 했습니다.
또한 주어진 개인 독후감 시간 10분 외에 공유할 내용이 더 있었다면 채팅방을 통해 공유하고 이 문서에 추가하여 레퍼런스를 잘 기록하고 싶었습니다.
마지막으로, 구성원들과 낙오자 없이 모두 완독하기 위해 서로 문장과 가치관과 경험을 나누다가 혹시 모를 실수로 불쾌감을 느꼈을 때는, 어차피 한번 보고 안 볼 사이인데 라고 하지말고 허심탄회하게 다함께 있는 자리에서 풀어서 완독이라는 목표 앞에서 갈등을 최소화하자고 그라운드 룰을 정했습니다.
구성원들에게 피드백 받을 체크 포인트를 정리했습니다.
-
10분은 적절했는지? (55분동안 5명이서 개인 독후감 나눔을 했어야 했기 때문에 10분으로 책정했었습니다.)
-
5~10 문장은 적절했는지?
-
뒤늦은 순서일수록 나누고 싶은 문장이 겹쳐서 나누고 싶은 문장을 말하기 애매해질 수 있는데 순서는 매번 어떻게 하면 좋을지?
피드백
아메리카노님
문장이 겹쳐도 경험이 다르고 중요하게 생각하는 이유가 다르니 겹치는건 크게 상관 없을 것 같습니다. 각자 5~10문장을 10분 내외로 나누면 시간 배분도 어느정도 될거같아요. 순서는… 잘 모르겠어요 ㅎㅎ 저는 상관 없습니다!
freebear님
제 피드백은 1, 2번: 10분 내외로 한다면 문장 수는 크게 개의치 않게 되는 것 같습니다.
3번: 순서는 그 날 첫 번째로 발표할 사람을 정하고, 그 다음 순서대로 하면 좋을 것 같아요
콘크리트장인님
- 다른 분들을 생각하면 10분 내외가 적당한 것 같습니다.
- 음 그것보다 적을 수도 있고 많을수도 있다고 생각합니다. 5-10에서 국한하지 않았으면 좋겠어요.
- 순서는 랜덤뽑기나 사다리타기 등 그때그때 정하거나 아니면 1번을 정하고 시계나 반시계로? 갔으면 좋겠습니다.
muki4742님
피드백 남겨 드립니다.
- 10분은 적절한 것 같습니다.
- 문장 제한은 없어도 될 듯 합니다.
- 순서를 로테이션으로 정하면 될 듯 합니다. ( 이번주는 토스님 부터 했으니, 다음주는 아빈님 부터 등 )
[ 기타 ]
- 한번 읽고 오는게 전제라고 하면, 30분 정도 다시 읽는 건 시간이 너무 긴듯 합니다.
- 한번 읽을 때, 말씀하셨던 5~10 문장들을 선별해 놓으면, 말할 것들을 정리하는데, 10~15분이면 충분할 것 같습니다.
[ 타임 테이블 ]- 0 ~ 15분 읽었던 내용 한번 보면서 말할 것들 정리하기
- 15분 ~ 65분 한명씩 말하기 ( 50분 )
- 65분 ~ 90분 서로 말한 것들에 대해서 이야기 하기
피드백 반영
- 1인당 개인 독후감 나눔을 10분 내외로 하기
- 나눌 문장의 개수는 자유롭게 하기
- 독서회에 와서는 정리와 나눔을 하는 시간으로만 사용하고, 할당 챕터는 반드시 읽어오기.
- 타임 테이블
- [0~15분] 정리
- [15~65분] 개인 독후감 나눔
- [65~90분] 서로의 개인 독후감에 대해 자율 나눔
독후감 문장
X (이 책의 대상 독자)
결론적으로 이 책을 읽는데 필요한 가장 중요한 준비물은 실무 프로그래밍 경험과 설계에 관해 고민한 시간이다.
4P
간단히 말해서, 우리가 어떤 프로그래밍 패러다임을 사용하느냐에 따라 우리가 해결할 문제를 바라보는 방식과 프로그램을 작성하는 방법이 달라진다.
5P
패러다임에 대한 공부는 과학도가 훗날 활동을 수행할 특정 과학자 공동체의 구성원이 될 수 있도록 준비시키는 것이다.
또한 객체지향에 대한 다양한 오해를 제거함으로써 객체지향 프로그래밍을 하는 개발자들이 동일한 규칙과 표준에 따라 프로그램을 작성할 수 있게 할 것이다.
6P
절차형 패러다임에서 객체지향 패러다임으로 전환됐다고 해서 두 패러다임이 함께 존재할 수 없는 것은 아니다.
프로그래밍 패러다임은 혁명적이 아니라 발전적이다.
'은총알은 없다.'는 프레디 브록스의 말을 기억하라.
7P
글래스의 결론을 한마디로 요약하면 이론보다 실무가 먼저라는 것이다. 따라서 어떤 분야든 초기 단계에서는 아무것도 없는 상태에서 이론을 정립하기보다는 실무를 관찰한 결과를 바탕으로 이론을 정립하는 것이 최선이다.
소프트웨어 분야는 아직 걸음마 단계에 머물러 있기 때문에 이론보다 실무가 더 앞서 있으며 실무가 더 중요하다는 것이다.
8P
이 책은 훌륭한 객체지향 프로그램을 설계하고 유지보수하는데 필요한 원칙과 기법을 설명하기 위해 쓰여진 책이다. 일반적으로 이런 종류의 책들은 객체지향에 역사를 장황하게 설명하거나 기억하기조차 버거운 용어와 난해한 개념들이 줄줄이 나열하는 것으로 시작되곤 한다.
설계 분야에서 실무는 이론을 압도한다. 설계에 관해 설명할 때 가장 유용한 도구는 이론으로 덕지덕지 치장된 개념과 용어가 아니라 ‘코드’ 그 자체다.
개발자는 구체적인 코드를 만지며 손을 더럽힐 때 가장 많은 것을 얻어가는 존재다.
14P
두 번째 목적은 변경을 위해 존재하는 것이다.
16P
가정이 깨지는 순간 모든 코드가 일시에 흔들리게 된다.
이것은 객체 사이의 의존성과 관련된 문제다. 문제는 의존성이 변경과 관련돼 있다는 점이다. 의존성은 변경에 대한 영향을 암시한다. 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼 있다. 그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답이 아니다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.
따라서 우리의 목표는 애플리케이션의 기능을 구현하는데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.
17P
따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
25P
핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메세지를 통해서만 상호작용하도록 만드는 것이다.
26P
객체는 자신의 데이터를 스스로 처리하는 자율적인 존재여야 한다.
변경은 버그를 부르고 버그에 대한 두려움은 코드를 변경하기 어렵게 만든다.
29P
따라서 객체가 어떤 데이터를 가지느냐보다는 객체에 어떤 책임을 할당할 것이냐에 초점을 맞춰야 한다.
설계를 어렵게 만드는 것은 의존성이라는 것을 기억하라. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것이다.
불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 훌륭한 객체지향 설계다.
33P
첫째, 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다. 둘째, 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드 오프의 산물이다. 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수는 없다.
35P
우리는 오늘 완성해야 하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야 한다. 좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계다.
변경을 수용할 수 있는 설계가 중요한 이유는 요구사항이 항상 변경되기 때문이다. 개발을 시작하는 시점에 구현에 필요한 모든 요구사항을 수집하는 것은 불가능에 가깝다. 모든 요구사항을 수집할 수 있다고 가정하더라도 개발이 진행되는 동안 요구사항은 바뀔 수 밖에 없다.
코드 수정은 버그가 발생할 가능성을 높인다. 버그의 가장 큰 문제점은 코드를 수정하려는 의지를 꺾는다는 것이다. 코드 수정을 회피하려는 가장 큰 원인은 두려움이다.
36P
변경 가능한 코드란 이해하기 쉬운 코드다.
메세지를 전송하기 위한 이런 지식이 두 객체를 결합시키고 이 결합이 객체 사이의 의존성을 만든다.
훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계다.
