임백준의소프트웨어산책-소프트웨어에대한새로운시선그리고통찰력(2007/10/20)
임백준 지음| 한빛미디어| 2005.05.30 | ISBN 897914329X (13560)


책읽고 요약하기를 반복한다고 전진하는 건 아니더라. 물론, 하지 않는 것 보단 낫다고 변명은 할 수 있겠지만, 권수 늘이기만 가지고 실력이 늘진 않는단 사실은 정해진 답이다.

가볍게 현재 위치에서 그가 가름해 놓은 몇 분야에 대해 정리해 볼 수 있어 좋더라! 다만, xp 컨설팅을 하고 있는 김창준씨를 알아서 일까?! 그가 말하는 TDD와 유닛테스트의 의도는 본질과 다른 그 무엇이 느껴지더라! 
참고] TDD에 대한 김창준씨의 짧지만 긴 여운의 동영상.
http://dory.mncast.com/mncHMovie.swf?movieID=10042747720070912135133&skinNum=1

아쉬운 건 그는 미국에 있으면서도 구루들 이야긴 전해 주지 않는다. 오롯시 그의 경험 안에서 이야기 한다. 그렇다고 신선함이 느껴지지 않고,

언제나 느끼는 것이지만, 궁극에 우린 자기化가 필요한 것이다. 거기에 타인의 인정을 통한, 자기자신을 이기는 극기와 더불어서 말이다. 실력없는 나의 짧은 식견으로 임백준이란 저자를 재단하기 위해 읽는 것은 아님을 잊지 않고자 한다. 그의 내공은 나보다 높다. 그랬기에 읽었다.

그가 가름한 분야 하나 하나가 또 큰 줄기인데 그것을 정리해 볼 요량으로 쓴 것은 욕심이겠거니 했다. PP를 쓴 사람들은 최소한 20년의 경험으로 시작했단 사실을 본다면 대단한 도전일 수도 있으나 그가 쓴 글이 존재하지 않는 이론이거나 요약이라고 보기엔 모자란 구석이 제법되기에 ... ... 모자르다란 표현보다 이런 표현이 정확하겠다. 어떤 어떤 부분에선 이렇게 설명했다면 더욱 단순명료하게 전달했지 않았을까!

통찰이란 단어를 쓴다는 건 저자의 나이가 꽤 되었을 것이라 짐작하게 한다. 아니더라! 그는 통찰이란 단어에 빚지고 사는 것이더라! 그랬기에 실력 있음을 보이려고 하는 것 같다. (존 마에다 교수는 [The Laws of Simplicity/단순함의 법칙] http://blog.jrcho.com/1210 의 서문에서  불가능함으로 포기했다)

[책 읽고서 생각한 내 역량강화]
이제는 내 분야에 대해서도 여유있는 시선과 배움, 애정으로 보고자 읽기 시작해야 한다. 미뤄둔 전공서를 제대로 읽고 정리해야 한다. 물론, 내공도 쌓고.
지금까지 내 공부와 관련한 읽기를 미루었을까? 정리해본 이유는 첫째, 배우는 법을 찾고 있다. 아직도 찾고 있냐고 하면 할 말 없다. 그렇다. 이젠 시작해야한다 이젠,이 변명도 통하지 않는다. 둘째, 조금 해보려 하면 어렵고, 타이핑 하기 싫었다는, 귀찮았다는 이유, 셋째, 내 분야의 지식은 거기가서 빠져들어 배울 수 밖에 없다는 고정관념. 이렇게 세가지를 찾아보았다.
현재의 내 수준을 솔직히 인정하고 받아들이고, 발전 모색해야 한다. [뉴욕의 프로그래머 http://blog.jrcho.com/1337  ], [달인 http://blog.jrcho.com/1331  ]을 통해 연결 사고를 해보았다는 것에 만족.  (바로 앞 두권이 좋았다는 이야기가 아니라 관을 만들어줄 재료가 되었다고 표현하는게 낫겠다.)

오픈소스를 통해서라도 코드 꾸준히 읽고 노력해야겠다 결심. 내가 잘하는 그 무엇에 집중해 경제적 자립(=부자가 되기)후 꿈 이루기를 해야 된다는 결론.

-책을 통해 배울 수 있는 지식은 한정적이며, 미래에 필요한 지식은 암묵지임을 경험을 통해 스승을 통해 배워야 됨을 잊지 말자!

[기억에 남는 구절]
패턴이라는 것은 사실 객체지향프로그래밍의 전유물은 아니다.-p49
=> 비동시성의 동시성
객체를 설계하는 전형적인 방법!-p49

smalltalk의 창시자 알란케이
"객체지향 프로그래밍에서 서로 다른 객체가 동일한 메세지에 대해서 저마다 고유한 방식으로 응답할 수 있도록 하는 것이 다형성이다."

module cohesion응집 -해당 업무와 관련된 코드만 존재
module coupling결속 -여러 개의 다른 모듈이 서로 연관되는 정도를 의미
응집 높아야 하고 결속은 낮아야 한다.

소프트웨어 공학에 따르면 오늘날의 소프트웨어 생산과정에서 가장 큰 비용이 들어가는 부분은 설계나 코딩이 아니다. 소프트웨어를 출시한 다음에 일어나는 유지보수(maintenace)이다.-p63

'이론'을 학습하는 것 보다는 코딩과 같은 구체적인 '행위'가 더 중요하다고 보았다.-p67
해커와 화가를 읽었는데, 저자가 위와 같은 의도로 적었는지 몰랐다.*_* 다시 읽어볼 예정

소프트웨어 시스템은 시간이 지남에 따라서 성장하도록 되어 있다.-p74

Refactoring, Reuse and Reality - p85

Posted by iarchitect