자바 개발자라면 한번 쯤 읽어보아야 한다고들 하는 책이다. 근데 생각보다 기대를 많이 하고 봐서 그런지 그렇~~게 감명깊지는 않았지만 재미있게 읽었다. 켄트 벡옹의 깊은 내공과 JUnit을 만들면서 했던 경험과 시행착오들이 많이 반영 된 것을 느낄 수 있었다(많이 언급 되기도 함). 

＜본문 p.27＞

  책의 구성은 위의 그림으로 모두 표현할 수 있다. 클래스의 행위와 상태를 토대로 그것들에 맞는 패턴들을 설명해 나가고 있다.

목차

1. 소개
2. 패턴
3. 프로그래밍 이론
4. 동기유발
5. 클래스
6. 상태
7. 행위
8. 메소드
9. 컬렉션
10. 발전하는 프레임워크
11. 부록A 성능 측정

  가치와 원칙, 패턴의 기치아래 구현 패턴의 이론적 토대를 설명한다. 

지금까지 살펴본 세 가지 요소인 가치, 원칙, 패턴을 사용하면 균형 있는 개발 스타일을 얻을 수 있다. 패턴은 지금 당장 무엇을 해야 할지를 알려주고, 가치는 패턴을 사용해야 하는 동기를 알려주며, 원칙은 동기를 행동으로 어떻게 바꿔줄지 알려준다. ＜본문 p.34＞

• 가치
• 커뮤니케이션
• 단순성
• 유연성
• 원칙
• 지역적 변화
• 최소 중복
• 로직과 데이터의 결합
• 대칭성
• 선언적 표현
• 변화율

  3장 프로그래밍 이론에 나오는 내용들인데 4장부터 뒤의 내용들을 굳이 보지 않더라도 가치와 원칙을 잘 지키려고 노력한다면 좋은 개발자가 될 수 있을 것이다. 4장부터의 내용은 그것을 더 쉽게 하기 위해 켄트 벡이 정리하고 경험한 내용들을 서술했다고 볼 수 있다.

  한 메소드 안에서 같은 추상화 레벨 유지하고 세부 구현은 최대한 숨겨서 코드를 읽기 쉽게 해야 한다는 부분이 가장 기억에 남는다. 실제 로직이 어떻게 되어있는지 궁금하다면 그 때 세부적으로 살펴봐도 늦지 않을 것이다. 추상화 레벨을 잘 유지하고 세부 구현을 숨김으로서 읽기 쉽고 깔끔한 코드를 만드는 것이 가장 중요하지 않을까 생각이 든다.

  몇가지 아쉬운 점은 실제 예제 코드를 많이 보여주었다면 더 좋지 않았을까 싶다. 예제 코드가 많이 없고 드문드문 있어서 설명을 읽어도 실제로 어떨때 어떻게 쓰이는지 이해하기 어려운 부분들이 종종 있었다. 또한 개발 서적인데 번역을 고려하지 않고 한 것 같다. 전용(private), 보호(protected), 공용(public), J유닛(JUnit) 등 차라리 그냥 원어로 쓰는 편이 더 좋았을 것들을 번역해서 오히려 읽기 어려웠다.

  77가지의 다양한 상황에서의 구현 패턴들을 설명했지만 결국 절대적인 답은 없다. 상황에 맞게 처지에 맞게 코드를 만들어 나가는 것이 답일 것이다. 

켄트 벡의 구현패턴, 에이콘(켄트 벡)

출처: http://countryxide.tistory.com/99 [배워서 남주자]

오랜 시간 프로그래밍을 해왔음에도 코딩, 설계 방식에 대한 뚜렷한 주관이 없다는것에 대한 부담감을 마음속에 항상 갖고 있습니다. 코딩이나 설계 스타일에 대한 문서라도 작성해 놓을걸 이라는 생각도 하고 실제 시도도 해보지만 글로 풀어 쓴다는것이 여간 힘든게 아닙니다. 막연히 머리로 생각하던것을 글로 쓸때 수반되는 적절한 단어에 대한 필요성을 충분히 충족시킬 자신이 없기 때문입니다.

간혹 오픈 소스등을 보다보면 맘에 드는 스타일이 보이곤 합니다. 그 부분을 현재의 방식과 혼용하다보면 나비효과 처럼 전혀 관련이 없을꺼라 생각되던 부분들까지 불가피한 변경이 일어나는 경우가 있습니다. 그럴수록 명확한 스타일에 대한 필요가 절실해지곤 합니다. 이런식으로 매번 고민하는 이유는 아마 기존의 스타일에 대한 확신이 부족하기 때문일것입니다. 구글에서 제시하는 코딩 스타일처럼 이유와 확신을 근거로 문서로 제공되어진다면 그것만큼 좋은건 없을 겁니다.

이런 생각들을 하고 있을 즈음에 보게된 것이 '켄트 벡의 구현 패턴'입니다. 저자의 서문을 보면 '다른 사람들이 이해하기 쉬운 코드를 만드는 프로그래밍에 대한 내용을 담고 있다' 라고 쓰여져 있습니다. 다른 사람들이 이해하기 쉬운 코드란 것이 어떤 것일까요? 본인의 속한 그룹에 의해서는 찬양 받는 스타일임에도 불구하고 그룹에 속하지 않은 다른 사람이 봤을때는 어렵게 보이는 문제에 대해서는 어떤 생각을 가져야 할까요?

제 경우에는 기존 팀의 스타일에 대해서 기존 그룹 구성원들은 모두 찬양하였지만 저만은 불편하고 어렵게만 느껴졌던 경험이 있습니다. 그 이유를 기존 팀원들은 초반부터 써왔기 때문이고 전 다른 스타일로 작업을 하다가 뒤늦게 프로젝트에 참여하게 되어 변화가 느린것이라 생각하였습니다. 즉 노출빈도에 따른 적응의 문제였다고 생각할 수밖에 없었습니다.

하지만 지금에 와서야 생각을 해보면 이유는 아마 스타일에 대한 가르침을 필요가 있을 경우에 적절하지 못한 말로 설명을 듣거나 기존에 코딩된 내용을 보고 따라 하면서 익혔기 때문이 가장 큰 것으로 보입니다. 만약 구글 코딩 스타일 처럼 스타일에 대한 이유와 상황이 문서로 존재하고 그걸 보고 배웠다면 조금은 더 빠른 시간안에 익숙해졌을거라 확신합니다.

예를 들자면 클래스 이름을 지어서 검수받을때 '이 클래스의 이름은 이것보다는 이게 더 나을거 같은데?' 라는 말을 들은 경우가 있습니다. '이거나 저거나 비슷해 보이는데 무슨 이유죠?' 라고 되물을 경우 '여기엔 이런 이름이 더 어울려' 라는 등의 왠지 불명확한 답변을 들을경우 이해하지 못하고 그냥 넘어간 경우가 있습니다.

만약 켄트 벡이라면 어떤식으로 우리를 이해시켜 주었을까요? 상위 클래스 이름을 지을때의 규칙은 무엇이 있는지 켄트 벡의 얘기를 들어보도록 하겠습니다.

클래스 이름을 지을 때는 간결성과 표현성 사이에서 고민하게 된다.이런 딜레마에서 벗어나는 방법은 메타포metaphor, 은유를 사용하는 것이다.

간결성, 표현성, 은유 이런 단어들을 보자마자 항상 머릿속으로만 고민하던 내용들이 이런 내용이었구나 란 생각과 함께 명확해짐을 느낄 수 있었습니다. 만약 '이 클래스에서는 이러한 이유로 인해 간결성이 있는 이름 필요하고 여기서는 표현성이 부각되어야 되요' 란 설명과 함께 가르침을 받았다면 그 이해도는 분명 달라졌을 거라 생각되어 집니다.

이런 클래스의 이름 짓는 방법에 대한 적절한 단어의 필요성을 찾던차에 보게 되어서 그런지 너무나 유익한 도움이 되었습니다. 다만 후반으로 갈수록 조금은 지루해지는 면이 있습니다. 아직 필요에 대한 요구가 없기 때문일수도 있고 별다른 코딩이 없이 개념만 나열하기 때문일수도 있습니다.

하지만 이 책은 한번 읽어서 정보를 얻고 덮는 책이 아닌 옆에 두고 주기적으로 반복해서 읽어야할 책 중의 하나라는 생각이듭니다. 이를 테면 프로젝트가 새로이 시작되는 시기라든가 프로젝트가 끝난후의 시점이 될수 있을것입니다.

만약 개발 경력이 오래 되지 않았다면 쉽게 와닿지 않는 그저 지루한 책에 불과할 수도 있습니다. 좋은 책이란 기본적으로 좋은 내용을 알려주어야 함은 물론이거니와 독자의 이해와 필요 요구가 함께 수반되어야 하기 때문입니다. 경험이 쌓일때마다 반복해서 읽어보시길 추천드립니다.

http://raid79.tistory.com/696

책을 받아보고 사실

두께가 생각보다 얇아서 조금 놀랐다.

보통 패턴책은 조금 두꺼운 감이 있는데 .

일단 기존에 패턴책과는 접근방법이 달랐다.

자바에 속성, 메소드, 클래스, 패키지

와 같은 그 구성구성을 어떻게 구성하느냐에 따라

코드간의 유연성 등이 어떻게 달라지는지에 대해서 다루고 있다.

자바의 구성단위를 다루었다는 점이 참 좋았던거 같다.

조금 아쉬웠던 점은

해당하는 점에 대한 예제가 조금더 많았었다면 하는 아쉬움이 있다.

그리고 용어의 경우

조금 익숙하지 않은 용어들이 조금 아쉬웠다

예를 들면 전역변수를 필드 라고 표현한듯 한데

필드라는 단어보단 전역변수가 나았지 않나 싶다.

이 책을 읽고

리팩토링이나 디자인 패턴 책을 읽으면 참 좋을거 같다.