[Book] 켄트 벡(kent beck)의 tidy first?

 

TDD, 익스트림프로그래밍으로 유명한 켄트 벡의 신작 Tidy first? 가 출간 되었다고 해서 허겁지겁 가서 책을 구매 후
책에 대한 리뷰를 이제야 남긴다.
Tidy first는 앞으로 켄트백이 생각하는 시리즈의 첫 권이다.

 

 

책의 이름과 구성

---

책의 제목

 

책의 이름은 물음표로 끝나는 의문형인데.

Tidy First?

tidy (adjective)
arranged neatly and with everything in order
- oxford dictionary -

코드를 깔끔하게 정리하는 것을 먼저 할 것인가?라는 제목으로 책내용을 일부 유추 해 볼 수 있다.
(tidy라는 것이 깔끔한 정리된 상태를 의미하는 것을 이번에 처음 알았다.)

 

구성

1. 본권

 

part1 코드 정리법
part2 관리
part3 이론
part4 문헌
(켄트 벡이 구체적인 것에서 추상적으로 가는 방향으로의 학습을 선호한다고 한 것만큼 책 목차에서도 잘 드러나 있다.)

2. 별책 부록 : 옮긴이의 노트

위와 같이 본권과 별책부록 두 권으로 나뉘어 있다.

본권은 참고문헌을 제외한 141p, 별책 부록은 99p로 책이 얇은 편인데

특별 서문에서 켄트 벡은 it 서적을 주로 읽는 대부분의 독자들이 많은 분량을 집중해서 읽지 않기 때문에 최소한의 분량으로 구성하려 했다고 한다 🤣🤣

 

안 하느니만 못할 우려가 있는 개념들이 아닌, 확실하고 자신 있게 설명할 수 있는 개념만을 담았다고 한다.

 

Part1 코드 정리법

---

 

그렇다면 Tidy라는 단어는 어떤 concept을 담고 있을까?

 

기능을 변경하는 것이 아닌 구조를 변경하는 것.
그 구조를 변경함으로써 가독성(읽기 더 수월해지고), 유연성(더 변경하기 쉬운 코드가  되며), 장기적으로 관리하기가 수월한 코드가 되는 한 번에 적용할 수 있는 작은 단위에 변화.

책을 보고 나서 나는 위와 같이 Tidy에 대해서 생각을 정리 해보았다.

part 1은 지저분한 코드를 마주칠 때마다 적용할 수 있는 아주 작은 움직임에 대해서 다룬다

 

보호구문, 도우미 메서드 추출,  설명하는 변수 및 상수 등.
코드를 클린 하게 작성하는, 리팩터링 관련해서 보았었던 책들에서 소개했던 방식들을 마주칠 수 있다.

 

옮긴이의 노트를 보면 켄트백은 fuzzy little refactoring이라는 단어에 대해서
"손에 작은 아기 오리가 있다고 상상해 보자" 라고 말을 한다.

정리에 대해서 어떤 위협이나 두려움이 느껴지지 않았으면 한다고 한다.

 

결합도 제거 비용 + 변경 비용 < 결합도에 따른 비용 + 변경 비용 

당장 어떻게 해야 할지 모른다면 결합도 제거가 곤란할 수 있다.
할 수 있더라도 당장 시간적 여유가 없다면 결합도 제거는 부담스러운 시간 투자가 된다.

팀이 이미 충분한 변경을 수행하고 있다면 결합도를 제거하는 일이 팀원 간의 잠재적 갈등으로 번질 수 있다.
(팀이 이미 충분히 많은 설계적 변경을 경험하고 있었다면, 이미 화가 난 상태일 수 있음.
팀이 변화를 받아들이기 위해서는 그전에 변화를 흡수할 시간이 필요하며, 그와 같은 상황일 때는 변화를 도입하기보다는 기다리는 편이 좋다.)

 

결합도 제거에 대한 현실적인 상황에 대한 말들이 잘 와닿았던 것 같다.

사실 현실적으로는 위와 같은 팀이 변화를 흡수할 시간이 주어지지 않으며,
때로는 모두가 변화를 하는 것에 동의를 하지 않는 상황도 존재하는 것 같다.

 

여러 개의 작은 조각의 코드를 하나의 더미처럼 느껴질 때까지 흩어진 코드들을 모아 보고 나서 깔끔하게 정리해 보세요.
코드 정리를 선행하면 더 작은 조각 단위로 결합을 제거하는 길을 제시하여 응집도를 높일 수 있습니다.
즉 실무적으로 한 번에 머리에 기억하고 있어야 할 코드의 상세 내용을 줄여 줍니다.

 

part 1은 what 어떤 것을 어떤 방식으로 수정해야 할지에 대해서,
코드정리를 어떻게 할지에 대해서 잘 설명해 준다.

 

Part2 관리

---

part2에서는 when, how 코드 정리를 언제 시작할 것이며, 언제 멈출 것이고,

구조 변경과 동작변경에 대한 결합을 어떻게 정리할 수 있을지에 대해서 다룬다.

 

단계의 크기는 본인이 알아서 하겠지만, 제가 권하는 것은 아주 작은 단계로 나누어 코드를 정리하는 방식을 고수하면서 실험해 보는 것입니다. 그러면서 각 단계를 최적화하세요.

코드를 대대적으로 바꾸려고 코드 정리를 시작하는 경우가 많습니다.
너무 많이, 너무 빠르게 변경하지 않도록 주의하세요.
작은 정리를 순차적으로 성공하는 것이 무리한 정리로 실패하는 것보다 시간을 아껴줍니다.

 

충돌, 상호작용, 추측으로 인한 비용이 증가됨에도 타협점을 찾으려고 노력합니다.
코드 정리 비용을 줄이고자 한다면, 코드 정리 개수를 늘려서 동작 변경에 소용되는 비용을 줄이세요. 그러면, 검토 비용을 줄일 수 있습니다.

 

리팩터링을 접근하는 방식을 프로세스적으로 가장 작은 단계에 코드 정리부터 시작하고 리팩터링을 하는 하나의 큰 작업이 아닌,

일상과도 같은 가볍고 부담 없이 아주 작은 단계로 나누어서 진행하기를 권장한다.

 

켄트벡은 마리화나를 접하면 추후 다른 마약에 손을 댈 수도 있다고 하여 마리화나를 gateway drug라고 하는 것에 빗대어
gateway refactoring라는 표현을 더불어 코드 정리가 더 어려운 설계 변경으로 이어지기를 의도한다고 말한다.

 

'이번 분기에는 기술 부채를 해결합시다!'라는 무거운 느낌의 리팩토링이 아닌,
하루하루 작은 코드 정리를 통해 소프트웨어나 도메인 내에서 더 나은 방향의 설계에 대한 실마리를 얻고, 조금씩 조금씩 설계를 변경하는 접근 방식은 부담을 줄이고 더 나은 설계를 향해 나아가는 길을 열어준다는 것.

작은 리팩토링이 모여 큰 변화를 일으키고, 더 나은 설계로 이어질 수 있다는 것 이라는 의미를 전달하는 것 같았다.

 

동작변경을 반영하면서 코드정리까지 같이 반영한다면 어떻게 해야 하는가? 🤔

1. 그대로 배포한다.
사람들이 무례하다 느끼고, 오류가 발생하기 쉽지만 당장 처리할 수 있다.

2. 코드 정리와 변경 사항을 별도의 하나 이상의 PR로 나누거나 하나의 PR을 여러 번 커밋으로 나눌 수 있다.
이 방법으로 무례함을 줄일 수 있으나 작업 횟수는 늘어난다.

3. 진행 중인 작업을 버리고, 코드 정리를 선행하는 순서로 다시 시작해 볼 수 있다.
이렇게 하면 작업은 더 많아지지만 이어지는 커밋과 일관성은 분명해진다.

 

사실 나는 코드 정리를 참지 못하고 1번처럼 배포한 경우도 종종 있어서 팀원들에 검토 비용을 올린 케이스가 있어서
2번처럼 하려고 노력하는 편이었다.
(작업단위를 매우 잘게 쪼개서 검토비용을 낮추는 것도, 코드 정리와 동작 변경의 얽힘을 풀어 검토 비용을 낮추는 것도 아직 미숙하다.)

동작 변경과 구조 변경이 얽혀 있다면, 어느 쪽을 택할까?
1. 실 환경에 바로 배포 하기..
2. 기존 변경 사항을 여러 diff로 나누어 풀어가기
3. 모두 버리고, 더 정리된 방식으로 모두 다시 구현하기.
10분 후에 엉킴을 잡으면 하루 후에 엉킴을 잡는 것보다 더 쉬운 결정입니다.
책에서 전략이 덜 중요해지는 상황을 의미합니다.

 

해당 문장이 이해하기가 좀 힘들어서 몇 번 본 것 같다.

스스로 나름 정리를 내려 봤는데.

문제를 미리 해결하면, 나중에 더 큰 문제로 번지기 전에 간단하게 처리할 수 있으므로

나중에 전략을 세울 필요가 줄어들어 전략이 덜 중요해지는 것을 의미하는 게 아닐까 라는 생각을 해보았다.

 

변경해야 되는 범주를 인식하고 정리를 선행한 뒤 동작 변경을 진행 하는 방식을 고려해보지는 않았는데 좋은 방식인 것 같다.

 

코드 정리 하리 말아야 할 때
1. 앞으로 다시는 코드를 변경하지 않을 때.
2. 설계를 개선하더라도 배울 것이 없을 때.

정리를 미룰 때
1. 정리할 코드 분량이 많은데, 보상이 바로 안 보일 때.
2. 코드 정리에 대한 보상이 잠재적일 때.
3. 작은 묶음으로 여러 번에 나눠서 코드 정리를 할 수 있을 때.

동작 변경 후에 정리할 때
1. 다음 코드 정리까지 기다릴수록 비용이 더 불어날 때.
2. 코드 정리를 하지 않으면 일을 끝냈다는 느낌이 들지 않을 때.

코드 정리 후에 동작을 변경 할 때
1. 코드 정리를 했을 때, 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효과를 얻을 수 있을 때.
2. 어떤 코드를 어떻게 정리해야 하는지 알고 있을 때.

 

Tidy First?  책이 의문형으로 끝나는 의미를 다시 한번 확인한다.
코드 정리를 먼저 해야 할까? 🤔

 

2부까지 보고 나니

코드정리를 언제 하는 게 맞을까?로 보이기 시작했고

정답이 없고 상황에 따라서 다르다는 게 느껴졌다.

 

Part3 이론

---

Part3는 Why 왜 코드 정리를 해야 하는지에 대해서 나온다.
what - when, how - why로 이루어지는 책의 구조가 참 마음에 든다.

 

Part3을 가장 좋아한다.
Part3에서의 켄트벡의 이전 금융권에서의 경험으로 코드 정리에 대한 당위성을
비용 기반으로 설명하는 접근 방식이 매우 흥미로웠기 때문이다.

 

Trade-Off
A trade-off(or tradeoff) is a situational decision that involves diminishing or losing on quality, quantity, or property of a set or design in return for gains in other aspects. In simple terms, a tradeoff is where one thing increases, and another must decrease. 
-wikipedia-

 

종종 우리는 Trade-Off 란 단어를 사용한다.

하나를 얻으면 하나를 잃게 되는 케이스에서 사용하고는 하는데
코드 정리 역시 Trade-Off가 존재한다.

why 그럼에도 왜? 해야 할까? 🤔

 

소프트웨어는 두 가지 방식으로 가치를 만듭니다.
1. 현재 소프트웨어가 하는 일
2. 미래에 새로운 일을 시킬 수 있는 가능성

 

어떻게 하면 더 나은 기계에 도달할 수 있을까요?
한마디로 말하면 선택 가능성입니다.
특정 방식으로 동작하는 시스템이 있다는 것만으로도, 시스템이 어떻게 동작해야 하는지에 대한 욕구가 달라집니다.
(하이젠베르크의 불확정성의 원리)
즉 현재 1$ per 10$ 기계에 얼마를 쓰고 있을지라도, 10$ per 100$, 1$ per 20$ 기계가 될 수 있는 기계에 더 많은 돈을 지불하게 될 것입니다.

 

시스템을 더 가치 있게 만들기 위해서 굳이 시스템의 동작을 바꿀 필요가 없었습니다.
다음에 무엇을 할 수 있는지에 대해 선택할 수 있는 기회를 만들자마자, 저는 이미 돈을 번 것입니다.

 

접근 방식이 매우 신선했다.

 

"소프트웨어는 결국 소프트웨어가 제공하는 가치로 인해서 누군가가 돈을 지불해야 한다"라는 생각에서 시작을 해보자.

현재 시스템이 특정 방식으로 동작하면, 이는 시스템이 어떻게 동작해야 하는지에 대한 새로운 요구를 만들어낸다.

켄트 벡은 하이젠베르크의 불확정성 원리를 차용하여, 시스템의 현재 상태와 미래 가능성에 대한 불확실성을 설명한다.

즉, 불확실한 미래에 대한 선택지를 많이 가진 시스템은 더 큰 가치를 지닌다.

 

Option에서 변동성이 커짐에 따라서 Option 가치가 커진다는 개념을 빗대서, 소프트웨어의 선택 가능성은 외부 환경의 변동가능성이 높을 경우 더 가치를 갖는다라고 설명한다.

 

https://www.investopedia.com/terms/v/volatility.asp

Volatility: Meaning in Finance and How It Works With Stocks

 

옵션에서 시간 경과에 따라 가치가 감소하는 타임 디케이(Time Decay) 개념도 중요한 요소이다.
시간이 지남에 따라 옵션의 시간 가치는 줄어든다.

 

https://www.investopedia.com/terms/t/timedecay.asp

What Is Time Decay? How It Works, Impact, and Example

 

오늘의 1달러가 내일의 1달러보다 더 가치 있기 때문에 버는 것은 빨리 하고, 쓰는 것은 가능한 뒤로 미룹니다. 혼란스러운 상황에서는 어떤 물건에 대한 옵션이 물건 자체보다 낫기 때문에 불확실성에 맞서는 옵션을 만듭니다.

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

 

이것이 소프트웨어 설계에 어떤 의미가 있을까요? 
소프트웨어 설계는 변화를 위한 준비로 동작 변경에 대한 준비입니다.

오늘 우리가 하는 설계는 내일의 동작 변경을 구매하는 옵션에 대해 지불하는 프리미엄입니다.

 

시간이 지남에 따라 선택지의 가치가 감소할 수 있다는 점을 고려해야 한다.

옵션의 시간 가치 개념과 유사하며, 코드 정리를 미룰수록 나중에 발생할 수 있는 변화에 대응하는 비용이 증가할 수 있음을 의미한다.

설계는 불확실한 미래에 대한 선택 가능성을 열어두는 유연한 설계를 지향해야 한다라고 말해주는 것 같았다.

현금흐름할인은 높은 확률로 먼저 돈을 벌고 낮은 확률로 나중에 돈을 쓰라고 말합니다.
코드 정리를 먼저 하지 마세요 돈을 더 일찍 쓰고 돈을 나중에 버는 것입니다. 
어쩌면 나중에는 정리가 필요하지 않을 수도 있습니다.

옵션은 나중에 더 많은 돈을 벌기 위해 설사 정확한 방법을 모르더라도 지금 돈을 쓰라고 말합니다.
옵션이 생길 일이 명백하다면 코드 정리를 선행하세요 동작 변경 후에도 정리할 내용이 있다면 또 합니다.

 

현금 흐름 할인이라는 개념을 활용해서 코드정리를 미루는 것을 설명한다.

초기 비용을 줄이고, 가능한 한 빨리 수익을 창출하는 것이 중요하며,
따라서 코드 정리를 나중으로 미루는 것이 경제적이라고 말한다.

 

위에서 말해 왔던 옵션 개념을 활용하여 미래의 불확실성을 대비하기 위해 현재 비용을 지출하라고 한다.
만약 코드 정리가 필요할 가능성이 높다면, 미리 정리를 통해 선택 가능성을 확보하는 것이 중요하다고 말을 한다.

비록 동작 변경 후라고 할지라도 정리할 내용이 있다면 또 해야 한다.

 

옵션에 대한 지식이 많지 않았고, 돈의 속성과 옵션에 대한 지식을 소프트 웨어 설계와 가치, 비용적인 측면으로 이어서 생각해보지 못했었기 때문에 위와 같은 관점은 매우 흥미로웠다.

 

비용(코드 정리)  비용(코드 정리 후 동작 변경) < 비용(바로 동작 변경)

 

확실히 코드 정리부터 해야 하는 케이스.

미리 정리를 통해서 더 나은 유연성을 갖게 되며 선택가능성을 확보하게 된다.

장기적으로 유지보수 비용을 절감하는 미래 비용 절감의 이점도 가질 수 있다.

 

비용(코드 정리)  비용(코드 정리 후 동작 변경) > 비용(바로 동작 변경)

 

곤란한 케이스이다.

 

단기적 경제성 때문에 코드 정리가 망설여지더라도 코드정리를 먼저 하고 싶을 수 있습니다.
그리고 코드 정리과정에서 자연스럽게 동작 변경까지 하고 있을 수도 있습니다.
모든 변경에 걸쳐 코드 정리에 드는 비용을 나누는 것이 합리적일 수 있으며, 심지어 현금흐름을 할인하는 것도 가능합니다.

 

 

고려 항목으로 위와 같이 말을 해주었는데 두 가지가 크게 이해가 되지 않아서 몇 번 봤던 기억이 난다.

 

모든 변경에 걸쳐 코드 정리에 드는 비용을 나누는 것이 합리적일 수 있다.

정리를 한 번에 크게 하기보다는,
지속적이고 점진적으로 수행하여 각 변경 사항에 부담을 분산시키는 것이 합리적일 수 있다.

 

현금흐름을 할인하는 것도 가능하다

지금 돈을 지출한다 즉 지금 코드 정리하는데 비용을 들이는 것도 가능하다.

 

단기적 경제성 때문에 코드정리가 망설여진다면

정리를 한 번에 크게 하기보다는 지속적이고 점진적으로 수행하여 부담을 분산시키면서 접근한다면

지금 비용을 지불하는 것도 가능하다라고 나름대로 이해를 해보았다.

 

창출된 옵션의 가치가 더 빨리 그리고 확실하게 돈을 지출함으로써 잃는 가치보다 크다면 현금흐름이 할인되더라도 코드 정리를 우선하는 것이 오히려 경제적으로 합리적일 수 있습니다.
이지점은 확고한 판단의 갈림길입니다.
여러분은 여기 좋은 게 더 있는데 그것을 보기 위해 코드 정리를 해야겠어라고 냄새를 맡을 수 있습니다.
이는 코드 정리를 더 해야 한다는 충분한 근거가 될 수 있습니다.

 

 

지금 까지 이야기해왔던 옵션의 가치는
선택가능성을 의미하고 미래의 변화에 대응할 수 있는 유연성을 의미한다.

코드 정리를 하는 단기 경제성이 크다고 하더라도,
비용을 지불 함으로서 추후 소프트웨어가 갖는 선택가능성, 옵션 가치가 현재 지불할 비용보다 크다면

지금 비용을 지불하더라도 코드 정리를 우선시하는 게 경제적으로 합리적일 수 있다라고 나름대로 이해해 보았다.

 

되돌릴 수 없는 설계 변경은 어떻게 하면 좋을까요?
서비스로 추출하기는 비교적 큰 문제이기 때문에 되돌리기 어려울 수 있습니다.
프로토 타입을 실제로 구현해 볼 수 있습니다.
즉 서비스로 추출하기를 적어도 당분간은 되돌릴 수 있게 만들고 있습니다.

 

코드정리를 먼저 할 수도 있지만,
결정을 번복하고 다시 코드 정리를 할 수 있다.

가역성을 기준으로 되돌릴 수 있는 구조변경의 중요성을 말해준다.

 

그럼 비용은 어떻게 알 수 있는가? 🤔

비용을 결합도를 기준으로 설명한다.

 

콘스탄틴 등가성

 

비용(전체 변경) ~= 비용 (큰 변경들)
비용(큰 변경들) ~= 결합도
비용(소프트웨어) ~= 비용(전체 변경) ~= 비용(큰 변경들) ~= 결합도
* ~= : 거의 같다

 

비용(소프트웨어) ~= 결합도

 

결국 소프트웨어 비용을 줄이려면 결합도를 줄여야 한다.

 

현금흐름할인은 일부 결합도를 설명합니다.
구현할 당시에 결합도가 있어도 구현하는 것이 경제적으로 올바른 결정이었습니다(수익은 먼저 비용은 나중에)
이제 그 나중이 왔습니다.

 

한 종류의 코드 변경에 대한 결합도를 줄일수록 다른 종류의 코드 변경에 대한 결합도는 커진다는 것입니다.
이것이 의미하는 실질적인 의미는 모든 결합을 다 색출하듯 없애려고 애쓰지 말아야 한다는 것입니다. (직관과 일치한다면)

 

위 내용에 대해서 약간은 공감했던 것 같다.

내가 아주 훌륭한 개발자가 아니라서 그런지는 몰라도.

사실 결합도라는 것을 아예 제거하는 것은 불가능하다.

기존 구조보다 더 좋은 개선된 형태의 설계 방식으로 기존의 높은 결합도를 개선했다고 할지라도,
또 다른 코드에서 결합도는 아주 약간이라도 올라가게 되었던 것 같다.

 

결합도 제거는 불확실하고 시간이 지남에 따라서 현금할인과 가치가 변하는 옵션을 만들어 낸다.

 

결론
비용 : 코드 정리를 하면 비용이 주는가? 아니면 나중에 해야 할까? 아니면 줄일 가능성이 있을까?
수익 : 코드를 정리하면 수익이 더 커질까? 혹은 더 빨리 발생하거나 커질 가능성이 있을까?
결합도 : 코드를 정리하면 변경에 필요한 요소의 수가 줄어들까?
응집도 : 코드를 정리하면 변경을 더 작고 좁은 범위로 집중시켜서 더 적은 수의 요소만 다룰 수 있을까?

 

누가?	언제?	무엇을?	어떻게?	왜?
독자	몇 분에서 몇 시간	코드 정리	구조나 동작 변경	결합도와 응집도

 

코드 정리에 너무 집착하지 마세요.

일반적으로 코드를 다룰 때 기능 변경에 대해서라면 자신이 옳다고 생각하는 일을 해도 사람들이 불만을 가질 수 있는 위험과 불확실성을 지닙니다. 반면에 코드 정리에 영향을 받을 사람은 바로 나 자신이기 때문에 만족할 가능성이 매우 높습니다.

한 가지 코드 정리를 하고 나면 다음 정리를 하고 싶은 충동이 생기겠지만, 억제해야 합니다. 또한, 코드 정리는 다음 동작 변경을 가능하게 합니다. 그러나 변경을 기다리는 다른 누군가가 기다리다 폭발하지 않도록 코드 정리를 나중에 해야 할 때도 있습니다.

코드 정리를 먼저 하실 건가요? 아마도요. 바로 그것입니다. 예, 여러분을 위해서 충분히 그만한 가치가 있습니다.

 

참 이랬다가 저랬다가 하라는 건지 말라는 건지 라는 생각이 들 정도로 끝을 맽는다.

책은 얇으나 뒤로 가면 뒤로 갈수록 확실하지 않고 생각을 많이 하게 된 책인 것 같다.

 

코드 정리를 해야 하는 상황들이 각기 너무나도 다르며 상황에 따라서 판단하에 진행을 해야 한다.

소프트웨어 가치와, 선택가능성 그리고 지금 현재 지불해야 할 비용을 기반으로 생각을 해볼 수 있다.

라고 어느 정도 생각을 정리했던 것 같다.

 

실제로 실무를 하면서 마주하는 결합도가 높은 코드들, 또는 동작변경과 구조변경이 얽혀있는 케이스 등에 대해서 켄트백이 했던 말을 근거로 간접경험을 나만의 경험으로 전환하는 과정이 없이,
책만으로는 아직 감이 크게 잡히지 않는 것 같다.

앞으로 생각나면 몇 번 더 찾아서 다시 한번 볼 것 같다.

 

옮긴이의 노트

---

끝으로

 

추가로 들어있는 옮긴이의 노트는

번역을 통해서 내용을 잘 전달하려는 안영회 님이 켄트백과 소통한 내용이 담겨 있다.

많은 고민을 하시고 많은 질문을 통해서 책의 내용을 독자들에게 잘 전달하려는 노력이 담겨 있다.

노력하신 안영회님에게 많이 감사하다는 생각이 들었다.

 

그리고 켄트백과 링크드인 DM을 한내용을 보는 것 자체도 참 재미가 있다. (켄트벡이 워낙 개발자 들에게 셀럽이라 그런가 ㅎㅎ)

 

뒤에는 안영회 님이 20년간 설계를 하시면서 겪어 오신 설계에 관한 글이 들어있다.

 

설계의 정의, 느슨한 결합, 설계가 할 수 없는 것 등

내용이 알차고 참 좋다.

 

책을 다 보고 옮긴이의 노트를 봤을 때 참 많이 뜻깊었던 것 같다.

 

끝으로

---

Tidy First?라는 질문으로

코드정리에 대해서 여러 관점에서 다시 한번 생각하게 되는 좋은 기회였던 것 같다.