[1일차] 19p.

코드 정리는 작은 리팩터링으로 누구도 싫어할 수 없을 정도로 사랑스럽고 포근합니다.

[2일차 -20p.]

데이터 종속을 수작업으로 분석한다면, 결국 실수를 하게 될 것입니다. 구조만 개선하려고 하다가 실수로 동작까지 변경하게 될 수도 있습니다. 그래도 문제는 없습니다. 올바른 버전의 코드로 되돌리면 됩니다. 작은 단계로 작업하세요. 그 방식이 바로 코드 정리 방법입니다. 커다란 설계 변경은 어렵고 무섭죠? 더 작은 단계로 진행하세요. 그래도 무섭다면, 더 작게 하세요. 두려움을 느끼지 않는 수준의 바로 그 단계가 가장 좋은 수준입니다.

[3일차 -20p.]

코드 정리는 자꾸 손이 가는 감자칩과 같습니다. 한 개를 먹으면 바로 또 먹고 싶어집니다. 따라서 코드를 계속 정리하고 싶은 충동을 관리하는 것도 코드 정리의 핵심 기술입니다. 방금 정리했는데 더 정리해도 될까요? 상황에 따라 다릅니다 (3부에서 어떻게 달라지는지 설명하겠습니다).

[4일차] 23p.

다음 상황에는 코드 정리를 하지 마세요. • 앞으로 다시는 코드를 변경하지 않을 때 • 설계를 개선하더라도 배울 것이 없을 때 다음 상황에서는 나중으로 정리를 미루세요. • 정리할 코드 분량이 많은데, 보상이 바로 보이지 않을 때 • 코드 정리에 대한 보상이 잠재적일 때 • 작은 묶음으로 여러 번에 나눠서 코드 정리를 할 수 있을 때 다음 상황에서는 동작 변경 후에 정리하세요. • 다음 코드 정리까지 기다릴수록 비용이 더 불어날 때 • 코드 정리를 하지 않으면 일을 끝냈다는 느낌이 들지 않을 때 다음 상황에서는 코드 정리 후에 동작 변경을 하세요. • 코드 정리를 했을 때, 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효과를 얻을 수 있을 때 • 어떤 코드를 어떻게 정리해야 하는지 알고 있을 때

[5일차 - 13p.]

• 잠재적인 동작 변경의 가치가 변동성이 클수록 더 좋습니다. • 개발 기간이 길면 길수록 좋습니다. 물론 앞으로 더 저렴하게 개발할 수 있다면 더 좋겠지만, 그것은 가치의 극히 일부분에 불 과했습니다. • 더 작은 설계 작업으로 옵션을 만들 수 있다면 더 좋았습니다.

[6일차 - 29p. ]

결합도 분석은 단순히 프로그램의 소스 코드를 보는 것만으로는 부족합니다. 두 요소가 결합되어 있는지 여부를 판단하려면, 먼저 어떤 변경이 발생했거나 발생할 가능성이 있는지 알아야 합니다 (테스트해 보려면 하나의 커밋에서 어떤 파일 쌍이 함께 나타나는 경향이 있는지 살펴보세요. 그런 파일들은 결합되어 있습니다.). 또한, 결합도는 소프트웨어 비용을 결정합니다. 결합도는 매우 근본적인 개념이기 때문에 저는 가능한 한 다양한 방식으로 표현하고 시각화합니다.

[7일차 - 22p. (이제부터는 부록입니다.)]

코드가 유기체와 같다고 느끼는 장면이 그런 부분인데, 그 많은 사연을 코드를 읽을 시점에 누가 나에게 알려주지 않습니다. 그렇게 막막해질 수 있는 나를, 혹은 그렇게 될 동료를 그대로 내버려둘 것인가요? 때로는 간결하게만 코드를 정리하는 것이 아니라 오히려 하나의 더미가 되게 뭉쳐야 한다는 사실은 모순처럼 느껴집니다만, 결국 프로그래머는 감정과 인지적 한계를 지닌 사람이고, 코드의 줄거리를 이해할 수 있는 상태가 된 이후에야 코드를 정리할 수 있다는 당연한 사실을 새삼 분명하게 인지하게 되었습니다.

[8일차 ] - 21p. (이제부터는 부록입니다.)

코드 정리를 토끼굴에 비유하여 시간을 낭비한다는 뉘앙스를 주는 것에 대해 주저되는데, 그걸 의도한 것이 맞나요? 비슷합니다. 사업하는 사람들은 동작 변경을 원합니다. 우리 프로그래머들 역시 그렇죠. 하지만, 우리는 동작 변경에서 벗어나 모든 가능한 구조 변경을 상상하고는 합니다. 그 지점이 코드를 정리하는 토끼굴에 빠지는 순간이죠. 하지만, 너무 빠지면 덜 중요한 일에 매달릴 수 있으니 주의를 기울여야 합니다.

[9일차]- 20p.

일단, 정원 관리와 프로그래밍의 연결은 생소할 수 있는데요. 이는 자신이 짠 코드를 다듬고 계속해서 잘 쓰이게 하는 일에 대한 은유 입니다. 정원 관리가 정원이 있는 집에 사는 대가로 치러야 하는 일상의 노력이듯 이 코드를 장기적으로 사용하려면 매번 기능을 추가하는 일과 별개의 노력을 들여 야 합니다. 개발자들은 이를 흔히 리팩터링이라고 부릅니다. 변수 이름을 성의껏 짓는 일처럼 작은 단위부터, 여러 곳에 흩어진 코드에 영향을 주는 구조적인 변경까지를 일컫는 말입니다.

[10일차] - 12p.

먼저 설계는 코딩을 대신 해 주지 않습니다. 두 번째로 기술적 가정을 검증하지 않고, 당장 개발을 위한 소 통에 쓰이지 않는 문서나 그림 형태로 설계하는 일은 지양해야 합니다. 그림을 그 리지 말라는 말이 아닙니다. 설계 결과물은 소통의 일부로, 함께 대화하는 맥락 (다른 말로 도메인이라고 함) 안에서만 힘을 갖는다는 말입니다.

[11일차] - 완독 (이제부터는 부록입니다.)

그럼에도 중요한 것은 형식이나 표기가 아닙니다. 개발자가 활용할 수 있도록 하는 설계 형식이나 표기라는 것에 정답은 없습니다. 다만 같은 상태도라도 본인의 경험에 따라 그것을 응용하는 방식이 달라지는 것뿐입니다. 개발자와 더 많이 소통하고 여러 번 프로젝트를 진행할수록 그것은 더욱 분명해집니다. 중요한 것은 어떤 모델링 기법으로 어떤 설계도를 그리느냐가 아니라 소통이 가능하게 하는 것이죠. 간단한 표를 활용해서도 전달하고자 하는 바를 전할 수 있습니다.