책: 켄트 벡의 Tidy First? - 한빛 서평

개요

한빛 미디어 서평단으로 “켄트 벡의 Tidy First” 의 서평을 하게되었다.

출간 소식을 듣고 서평단이 되지 않았더라도 읽어야지 했던 책이었다.

알라딘 링크: http://aladin.kr/p/cqor7

감상

감상, 밑줄, 생각을 적어둔다.

박성철님의 추천사

켄트 벡은 너무 미세해서 사람들이 종종 무시하는 ‘불안’이 소프트웨어 설계에 어떤 영향을 미치는지 간파합니다. p9

OOP, MSA, DDD 같은 거대 담론도 코드 정리에서 출발하지 않으면 그저 사변적인 것이 머물게 될 것입니다. p9

박성철님이 중용, 혹은 유교 경전을 읽어오시지 않았나 싶다. 유교의 말씀들이 떠올랐다.

• 막현호은, 막현호미 - 숨은 것처럼 잘 드러나는 것은 없으며, 미세한 것처럼 잘 나타나는 것은 없다.
• 행원자이, 등고자비 - 먼 곳을 갈 때에는 반드시 가까운 곳에서 시작해야 하고, 높은 곳을 오를 때에는 반드시 낮은 곳에서 시작해야 한다.

책의 구조

1부 코드 정리법: 코드를 정리하는 실제 방법들

2부 관리: 코드 정리는 작은 일이다. 특정 코드를 변경하려다 보니 하게 되는게 코드 정리이다.

3부 이론: 소프트웨어 설계에 대한 켄트 벡의 생각

1부. 코드 정리법

구체적인, 실제적인 것인 코드 정리법에서 책을 시작하여 점차 추상으로 나아가려 한다.

코드 정리는 리팩터링의 부분집합으로 보면 되겠다. 부담되지 않는 작고, 즐거운 작업

1장에서 15장까지 이야기하는 코드 정리의 방법들을 읽고 이해하고 사용하며 내 것으로 만들어두자.

2부. 관리

코드 정리는 괴짜의 자기 관리입니다. p69

2부의 목표는 코드 정리법을 개발 흐름에 자연스럽게 녹여 내는법이라 이해해본다.

켄트 벡은 이 책을 포함하는 3부작을 다음과 같이 구상하고 있다.

• 1권(이 책): 코드 정리는 프로그래머 자신에게 초점을 둔 소프트웨어 설계이다. 코드와 프로그래머, 프로그래머 자신과의 관계를 다룬다.
• 2권: 팀이 소프트웨어 설계를 함께 하는 방법과 이유
• 3권: 개발자가 아닌 사람들과의 관계에서의 소프트웨어 설계와 그 역할

코드 정리(책에서는 구조 변경이라고도 한다)와 동작 변경은 별도의 PR로 처리한다.

코드 정리는 자꾸만 이어서 좀 더 하고 싶어지는 작업이다. 작은 정리를 순차적으로 해보자.

팀에 신뢰와 강력한 문화가 있다면 코드 정리 후에는 굳이 검토할 필요가 없습니다. 84

켄트 벡은 코드 검토(= 코드 리뷰로 보인다)에 대해 부정적인 것으로 보인다.

코드 정리는 한 시간을 넘지 않도록 하자.

코드 정리와 동작 변경을 뒤섞어 해버렸다면? 과감하게 지금까지 한 것을 버리고 코드 정리부터 다시 시작하자.

• 정현석: 하나의 코드 리뷰를 마치고 이어서 다음 코드 작업을 해야한다는 부담감에 이렇게 잘 안하는 것 같다. 이 때문에라도 켄트 백이 코드 검토라는 단계에 대해 부정적인건 아닐까?

동작 변경과 코드 정리의 순서, 코드 정리의 시점은 무얼까? 정답은 없다. 상황에 따라 최적의 순서를 선택하자. 상황에 따라 1) 코드 정리를 하지 않거나 2) 정리를 미루거나 3) 동작 변경 후에 코드 정리를 하거나 4) 코드 정리부터 하고 동작변경을 할 수 있다.

3부. 이론

1부에서 코드 정리하는 구체적인 방법을 배웠고, 2부에서는 언제, 어떻게, 얼마나 하는지를 이야기했다. 3부에서는 왜 하는지 이유를 알아본다.

3부에서의 질문들

1. 소프트웨어 설계란 무엇인가?
2. 소프트웨어 설계와 소프트웨어 개발/운영 비용의 관계는 어떠한가?
3. 소프트웨어 구조 변경 여부와 방법의 결정에 사용할 수 있는 경제적, 인간적 원칙

소프트웨어 설계란 무엇인가?

‘소프트웨어 설계의 의미’에 대해 ‘요소들을 유익하게 관계 맺는 일’ 이라고 말할 수 있습니다. p99
Software design is beneficially relating elements.(원문)

위와 같은 관점에서 소프트웨어 설계란 다음을 하는 것이다.

요소를 만들고 삭제합니다. 관계를 만들과 삭제합니다. 관계의 이점을 높입니다. p102

구조 변경(코드 정리)과 동작 변경은 모두 가치를 만들어내지만 근본적으로 가역성(되돌릴 수 있는가)이 있는가가 다르다. 둘 중 어느게 나은가가 아니라 둘을 어떻게 조화시키는 가가 중요하다. 동작 변경을 먼저 돈을 버는 것이고, 구조 변경은 옵션을 만드는 것이다.

소프트웨어 설계는 ‘먼저 벌고 나중에 써야 한다’와 ‘물건이 아닌 옵션을 만들어야 한다’는 두 가지 속성을 조화시켜야 합니다. p110

옵션

“다음에 어떤 동작을 구현할 수 있을까?”

이때까지 저는 지금까지 한 일에 대한 대가를 받고 있다고 생각했습니다. 하지만 실제로는 그렇지 않았습니다. 대부분은 다음에 할 수 있은 일에 대한 대가를 받고 있었습니다.

”다음에 어떤 동작을 구현할 수 있을까?” 라는 질문은 동작 후보 목록이 많을 수록 더 가치가 있습니다.
최고의 교훈은 바로 이것입니다. 가치에 대한 예측이 불확실할수록 바로 구현하는 것보다 옵션이 지닌 가치가 더 커집니다. p115

 

이 책의 가장 핵심이 되는 지점이라 생각한다. 당장 돈이 될 것이라 생각하고 동작 변경을 열심히 하고 있는데 요구사항이 바뀐다면? 모두 날리고 새로이 코드를 짜야 한다. 하지만 다음에 할 수 있는 일이 많은 코드를 짠다면? 요구사항에 변화가 많은 상황에서 코드는 매우 높은 가치를 지니게 될 것이다. 그리고, 현대의 많은 요구사항들은 변화가 많다.

콘스탄틴의 등가성

1. 소프트웨어에서 비용이란 전체 변경을 하는데 드는 비용이다.
   • 그런데 전체 변경 중에서 큰 변경들이 차지하는 비용이 대부분이다.
2. 따라서, 소프트웨어에서 비용이란 큰 변경들의 비용이라 할 수 있다.
   • 그런데 비용은 결합도가 높을 수록 비용이 올리간다.
3. 따라서, 소프트웨어에서 비용은 결합도가 높을 수록 올라간다고 볼 수 있다!
   • 따라서, 소프트웨어 비용을 줄이려면, 결합도를 줄여야 한다.

기타등등

번역에 대하여

켄트 벡이라는 이름은 도그마 까지는 아니라 하더라도 개발자들에게 그 무게가 결코 가볍지 않다.

그러다 보니 역자는 켄트 벡의 표현 하나, 의미 하나까지 놓치지 않고 최대한 반영하여 번역을 하려 노력한 것으로 보인다. 그 결과로 100 페이지 남짓의 이 책을 술술 읽히지 않는 지점들이 있다. 소설가 한강이 부커상을 받았는데 창작 수준으로 영어 번역된 지점이 논란이 된 적이 있었는데, 그러한 문학 작품이 아닌 개발서적이라면 책을 읽는 개발자 독자들에 좀 더 무게를 실어서, 읽고 이해하기 쉬운 글로 번역을 했으면 어땠을까 싶다.

링크에 대하여

옮긴이 노트의 주석에는 링크들이 나오는데 따라치기에 불가능한 수준이 많았다. 적어두기는 하는데 누가 이걸 타이핑해서 찾아보겠어? 라는 마음이었을까 싶은데, 그럼에도 불구하고 단축 URL과 같은 방식으로 제공했으면 어떠했을까 싶다.

번역에 대한 감사

기타등등에 싫은 소리를 적어 놓았지만, 옮긴이 노트라는 별도의 형식으로 번역과정의 에피소드와 역자의 소프트웨어 설계에 대한 생각을 나누어 주신 것에 감사한 마음이 들었다. 당장은 읽기 힘들다 불평했지만 저자의 생각을 하나라도 놓치지 않으려 노력한 번역이기에 꼼꼼히 곱씹으면 그 맛을 알 수 있는 번역이라 할 수 있을 것이다.

마무리

이 책은 켄트 벡이  “Helping geeks feel safe in the world (괴짜들이 세상에서 안전하다고 느끼도록 돕는다)”는 사명에 충실하려 살아온 고민이 녹아있는, 개발자라면 꼭 읽어야 할 책임에 틀림없다. 다음 시리즈의 책들이 나올때마다 정독, 재독을 할 것이고, 당장은 1부의 코드 정리법을 나만의 언어로 하나씩 정리해보려 한다.

"한빛미디어의 도서 지원을 받아 작성한 리뷰입니다."