<div id="readability-page-1" class="page"><div><p>이 책을 읽다보니 저자가 중점을 두고 설명하려는 내용(예를 들면 소제목에 표현된 것들) 외에 그냥 흘려 얘기하는 듯한 설명 속에서 번뜩이는 영감을 얻는다. </p>
<h3 id="거꾸로-코딩하기">거꾸로 코딩하기</h3>
<p>켄트벡은 루틴의 마지막 줄부터 코드 작성을 시작해 보라고 조언한다. 테스트 코드를 먼저 작성하라는 얘기는 들어봤다. 그러면 테스트를 성공하는데 필요한 알짜 코드만 작성하게 된다고 했다. (실제로 해보면 그런 장점이 있다) 그런데 루틴의 결론부터 거꾸로 코드를 작성해 보라는 조언은 처음 들어 본다. 마치 마지막 줄에 이르기 까지 필요한 결과는 모두 확보한 듯이 코드를 짜보라고 저자는 조언은 신선하다. 시도해 봐야겠다.</p>
<h3 id="섞으면-안-되고요">섞으면 안 되고요</h3>
<p>켄트벡은 코드를 독자가 읽고 이해하기 쉬운 순서도 다시 정렬하는 일을 하라고 말하며 한 가지 조언을 추가한다. 이 때 다른 코드 정리 작업을 함께 하고픈 유혹이 있을 수 있고 그 유혹을 뿌리치라고 단호히 얘기한다. 섞으면 안 되고요! 내가 자주 받는 유혹이기도 하고 한 가지 일의 집중을 흐리는 일이라 정신을 번뜩 차리게 되는 조언이다. 뒤의 다른 챕터에 나오지만 코드 정리에 대하 커밋과 동작 변경에 대한 커밋을 분리하라고 켄트벡은 조금 더 진보한 조언도 준다. </p>
<h3 id="기다리는-것이-좋습니다">기다리는 것이 좋습니다</h3>
<p>이 내용은 ‘응집도를 높이는 배치’ 라는 챕터에 페이지 하단의 작은 주석으로 등장한다. 주석의 일부 내용을 그대로 옮긴다. 팀이 변화를 흡수할 시간을 주고 기다리는 것이 좋다. </p>
<blockquote>
<p>때때로 팀이 이미 화가 난 상태일 수 있습니다. 최근에 설계가 얼마나 바뀌었는지를 따지면서 말이죠. 팀이 많은 변화를 받아들이기 위해서는 그전에 변화를 흡수할 시간이 필요합니다. 이런 경우라면 추가적인 변화를 도입하기 전에 기다리는 것이 좋습니다.</p>
</blockquote>
<h3 id="두려움을-느끼지-않는-수준">두려움을 느끼지 않는 수준</h3>
<p>켄트벡은 작은 수준에서 설계 변경을 해보라고 권한다. 작게의 기준은 무엇인가 하면 두려움을 느끼지 않는 수준, 딱 그 수준이 가장 좋은 수준이라고 권한다. 너무 큰 덩어리를 한 번에 고치려 하면 어디가 어떻게 깨질지 몰라 두려움을 느끼곤 한다. 내 안의 두려움을 기준으로 적정한 수준으로 계속 개선해 나가길 조언하는 그의 조언이 따뜻하게 느껴진다. 그러나 때때로는 두려움을 이겨내고 Go 해보는 일도 필요하다는 생각도 가끔은 한다.</p>
<h3 id="빈-줄로-분리하기">빈 줄로 분리하기</h3>
<blockquote>
<p>긴 코드 덩어리를 읽다가 ‘아, 이 부분은 이렇게 하고, 저 부분은 저렇게 하는구나’라고 구분이 될 때는 두 부분 사이에 빈 줄을 넣어 분리합시다.</p>
</blockquote>
<p>빈 줄이라는 간단한 도구로 코드를 더 낫게 개선할 수 있다는 그의 조언에 살짝 놀랬다. 빈 줄이라는 도구는 늘 상 사용하고 있었던 것 같다. 그러나 이걸 이렇게 명시적으로 말해 준 사람은 처음인 것 같다. 흐리멍텅하게 가지고 있던 개념에 분명한 한 획을 그은 느낌이 든다. </p>
<h3 id="시간적-결합을-코드에-명시하기">시간적 결합을 코드에 명시하기</h3>
<p>켄트벡은 아래와 같은 코드가 있고, a() 는 반드시 b() 보다 앞서 호출해야 하는 제약이 있다면 다음과 같이 코드를 변경해 보라고 권한다. 구체적이고 좋은 조언인 것 같다. </p>
<pre><code><span>// before</span>
foo<span>.</span><span>a</span><span>(</span><span>)</span>
foo<span>.</span><span>b</span><span>(</span><span>)</span>

<span>// after</span>
<span>ab</span><span>(</span><span>)</span>
	<span>a</span><span>(</span><span>)</span>
	<span>b</span><span>(</span><span>)</span> </code></pre>
<h3 id="코드를-많이-작성해-보세요">코드를 많이 작성해 보세요</h3>
<p>끝으로 나는 이런 종류의 책을 읽다보면 한 온라인 개발자 서밋에서 아웃사이더라는 닉네임으로 알려진 변정훈님께 들은 조언이 떠오른다. 그는 개발자들에게 무엇보다 코드를 많이 작성해 보라고 조언했다. 정확한 워딩은 기억나지 않지만 좋은 코드에 대한 책을 읽고 고민을 많이하는 것도 좋지만 나쁜 코드일지라도 직접 많이 작성하고 느껴보는 것이 좋다고 했다. 그의 말에 동의한다. 이런 책의 내용에 감명을 받았을지라도 스스로 코드를 작성해 보고 느껴보지 않으면 나의 것이 되지 않는 것 같다. 시간이 많이 흘렀지만 아직까지 코드를 작성하는 엔지니어로 남아 있는 내가 좋다. 책의 내용들을 적용하고 느껴봐야겠다.</p></div></div>

Joo's Work

JooSing

이 책을 읽다보니 저자가 중점을 두고 설명하려는 내용(예를 들면 소제목에 표현된 것들) 외에 그냥 흘려 얘기하는 듯한 설명 속에서 번뜩이는 영감을 얻는다. 
거꾸로 코딩하기
켄트벡은 루틴의 마지막 줄부터 코드 작성을 시작해 보라고 조언한다. 테스트 코드를 먼저 작성하라는 얘기는 들어봤다. 그러면 테스트를 성공하는데 필요한 알짜 코드만 작성하게 된다고 했다. (실제로 해보면 그런 장점이 있다) 그런데 루틴의 결론부터 거꾸로 코드를 작성해 보라는 조언은 처음 들어 본다. 마치 마지막 줄에 이르기 까지 필요한 결과는 모두 확보한 듯이 코드를 짜보라고 저자는 조언은 신선하다. 시도해 봐야겠다.
섞으면 안 되고요
켄트벡은 코드를 독자가 읽고 이해하기 쉬운 순서도 다시 정렬하는 일을 하라고 말하며 한 가지 조언을 추가한다. 이 때 다른 코드 정리 작업을 함께 하고픈 유혹이 있을 수 있고 그 유혹을 뿌리치라고 단호히 얘기한다. 섞으면 안 되고요! 내가 자주 받는 유혹이기도 하고 한 가지 일의 집중을 흐리는 일이라 정신을 번뜩 차리게 되는 조언이다. 뒤의 다른 챕터에 나오지만 코드 정리에 대하 커밋과 동작 변경에 대한 커밋을 분리하라고 켄트벡은 조금 더 진보한 조언도 준다. 
기다리는 것이 좋습니다
이 내용은 ‘응집도를 높이는 배치’ 라는 챕터에 페이지 하단의 작은 주석으로 등장한다. 주석의 일부 내용을 그대로 옮긴다. 팀이 변화를 흡수할 시간을 주고 기다리는 것이 좋다. 
때때로 팀이 이미 화가 난 상태일 수 있습니다. 최근에 설계가 얼마나 바뀌었는지를 따지면서 말이죠. 팀이 많은 변화를 받아들이기 위해서는 그전에 변화를 흡수할 시간이 필요합니다. 이런 경우라면 추가적인 변화를 도입하기 전에 기다리는 것이 좋습니다.
두려움을 느끼지 않는 수준
켄트벡은 작은 수준에서 설계 변경을 해보라고 권한다. 작게의 기준은 무엇인가 하면 두려움을 느끼지 않는 수준, 딱 그 수준이 가장 좋은 수준이라고 권한다. 너무 큰 덩어리를 한 번에 고치려 하면 어디가 어떻게 깨질지 몰라 두려움을 느끼곤 한다. 내 안의 두려움을 기준으로 적정한 수준으로 계속 개선해 나가길 조언하는 그의 조언이 따뜻하게 느껴진다. 그러나 때때로는 두려움을 이겨내고 Go 해보는 일도 필요하다는 생각도 가끔은 한다.
빈 줄로 분리하기
긴 코드 덩어리를 읽다가 ‘아, 이 부분은 이렇게 하고, 저 부분은 저렇게 하는구나’라고 구분이 될 때는 두 부분 사이에 빈 줄을 넣어 분리합시다.
빈 줄이라는 간단한 도구로 코드를 더 낫게 개선할 수 있다는 그의 조언에 살짝 놀랬다. 빈 줄이라는 도구는 늘 상 사용하고 있었던 것 같다. 그러나 이걸 이렇게 명시적으로 말해 준 사람은 처음인 것 같다. 흐리멍텅하게 가지고 있던 개념에 분명한 한 획을 그은 느낌이 든다. 
시간적 결합을 코드에 명시하기
켄트벡은 아래와 같은 코드가 있고, a() 는 반드시 b() 보다 앞서 호출해야 하는 제약이 있다면 다음과 같이 코드를 변경해 보라고 권한다. 구체적이고 좋은 조언인 것 같다. 
// before
foo.a()
foo.b()
// after
ab()
    a()
    b() 
코드를 많이 작성해 보세요
끝으로 나는 이런 종류의 책을 읽다보면 한 온라인 개발자 서밋에서 아웃사이더라는 닉네임으로 알려진 변정훈님께 들은 조언이 떠오른다. 그는 개발자들에게 무엇보다 코드를 많이 작성해 보라고 조언했다. 정확한 워딩은 기억나지 않지만 좋은 코드에 대한 책을 읽고 고민을 많이하는 것도 좋지만 나쁜 코드일지라도 직접 많이 작성하고 느껴보는 것이 좋다고 했다. 그의 말에 동의한다. 이런 책의 내용에 감명을 받았을지라도 스스로 코드를 작성해 보고 느껴보지 않으면 나의 것이 되지 않는 것 같다. 시간이 많이 흘렀지만 아직까지 코드를 작성하는 엔지니어로 남아 있는 내가 좋다. 책의 내용들을 적용하고 느껴봐야겠다.

Tidy First

댓글