리듬감을 잃지 않는 수준으로 구조 변경과 동작 변경을 하자

소프트웨어 설계를 길을 닦는 일과 비유한 것이 굉장히 인상깊게 다가옵니다.

소프트웨어 설계는 ’길을 닦는’ 일의 성격이 매우 강하기 때문입니다. - p.86

왜냐하면 길을 닦을 때 설계자가 의도적으로 만들 수도 있지만 사용자에 의해 만들어진 것을 드러내고 정리 할 수도 있기 때문입니다.

최근에 저도 비슷한 것들을 주의깊게 보곤합니다. 어떤 건물을 가보면 설계자가 의도에서 만든 길들이 있음에도 불구하고 사용자들이 만들어 가는 길도 있습니다. 이럴 때 재미있는 현상은 건물 관리자들은 사용자들이 만들어가는 길응 잔디를 보호 한다는 명목하에 사용하지 못하도록 막는 경향이 있습니다.

이를 켄트 벡의 비유에 적용해 보면 사용자들이 만들어가는 설계를 설계자들의 의도에 맞지 않는다는 이유로 부정하는 행위라는 생각이 듭니다.

또한 최근에 온보딩을 위해 여의도 IFC 몰에 있는 주차 프로세스를 경험한 적이 있는데요. 이 때에도 설계자들이 정의한 구조를 운영자들이 자유롭게 응용하며 쓰는 것들도 재미있게 다가왔습니다.

가령, 특정한 길을 막아 흐름을 다른 곳으로 유도하거나 특정 주차구역은 사용하지 못하도록 막거나 새로운 공간을 주차구역으로 응용하는 등 굉장히 다양한 형태로 쓰이는 것을 보면서 초기 설계대로 운영이 되는 것은 힘든 일이라는 것을 느꼈고, 운영을 하면서 드러내는 구조들이 새로운 설계로 볼 수 있겠다는 생각이 들었습니다.

이쯤해서 캔트 백은 왜 이 장의 제목을 리듬으로 지었을까요?

저 스스로 이해한 것은 코드 정리 와 동작 변경간의 균형이라는 생각이 들었습니다.

균형이라고 생각한 이유는 코드 정리나 동작 변경간의 적절한 조화를 말하고 있다는 생각이 들었기 때문입니다. 구체적으로 말해보면 코드 정리를 최소한만 하는 것도 아니고 한도끝도없이 하는 것도 아닌 동작 변경에 영향을 주는 적정 수준으로 코드 정리를 하라고 느꼈습니다.

그리고 이의 정량적인 수치로 몇 분 에서 한시간이라고 제시를 하기도 합니다.

특히 파레토 법칙를 인용하며 80%의 변경사항이 20% 파일에서 발생 한다는 법칙은 작은 범위의 코드 정리가 대부분의 동작 변경에 영향을 준다는 것을 설명하는데 의미있는 근거 라는 생각도 들었습니다.

코드 정리와 동작 변경의 리듬 설계

소프트웨어 설계를 프랙탈이라고 정의 내린 것이 인상 깊었습니다. 그 대상이 프랙탈인 것도 있지만, 명확하게 정의를 내렸다는 것이 인상 깊었습니다.

리듬이라는 것이 사전적으로 일정한 규칙에 따라 반복되는 움직임을 뜻하는데, 하나의 동작 변경에 대한 사이클 내에서의 패턴으로 받아 들였습니다. 왜냐하면 그 크기와 처한 상황이 매번 다르고 변경에 대한 욕망이 생겼을 때 코드 정리와 동작 변경에 대한 패턴 즉, 리듬이 유효하게 작용 하겠다고 생각했기 때문입니다. 그래서 한편으로 변경에 대한 욕망이 없는 곳에 코드 정리는 건물 사이에 수많은 통행로를 만드는 일이라는 생각이 들었습니다.

마지막으로 건물 사이에 잔디를 심은 사례를 통해, 실무 관점에서 실 사용자에 대한 데이터 분석이 중요하다고 다시 한 번 생각 했습니다. 애플리케이션을 개발하는 구성원으로서 기능을 구현 했다고 끝이 아니라, 이게 어떻게 사용되는지 지켜보는 것도 못지 않게 중요합니다. 사용자의 가려운 곳을 긁어줘야지 가렵겠다고 생각한 부분만 긁어대면 가려운 채로 상처만 남습니다.

생각이 이 부분에 도달했을 때, XP 에서 실패를 준비하지 않는다는 내용이 떠올랐습니다. 실패를 준비하지 않으면서, 사용자의 흔적(데이터)을 통해 받은 피드백에 동적으로 반응하며 유의미한 동작 변경 리듬을 가져가 보도록 노력해야 겠습니다.

코드 정리는 작은 설계 활동이다

소프트웨어 설계는 프랙탈이므로 설계는 크게도 작게도 할 수 있습니다.

XP에서는 프랙탈 개념을 '자기 유사성'으로 설명하고 있습니다.

자연은 어떤 형태가 효과적이라는 사실을 발견하면, 그 형태를 이용할 수 있는 곳이라면 어디에나 그것을 이용한다. - XP

웅장한 설계도 설계입니다. 도해도 설계입니다.
작은 설계도 설계고 코드 정리도 설계입니다.

리듬 유지하기 위한 제약 시간

이 책의 목적에 따라 소프트웨어 설계에 대한 한 가지 척도를 제시합니다. 바로 개인에게 영향을 미치는 소프트웨어 설계죠. 그래서 분 단위를 유지하되, 한 시간을 넘지 않습니다. 한 번의 코드 정리에 한 시간 이상이 걸린다면, 이는 원하는 동작 변경을 위해 필요한 최소한의 구조 변경 시기를 놓쳤다는 의미일 수 있습니다.

저는 지난 장들(Chapters)에서 제약이론을 언급하며
스스로 코드 정리를 10분 제약함으로써 느꼈던 효능감을 공유했습니다.
<Tidy First?>가 지향하는 바와 동일함을 글로써 확인합니다.

리듬 유지하기 위한 멈추기

켄트 벡은 전작 TDD에서도 리듬을 말하고 있습니다.
Red -> Green -> Refactor

위키를 만든 전설적인 프로그래머 워드 커닝햄 조차도 한 번에 좋은 코드는 만들기 어렵다고 말하고 있습니다. 그리고 이런 말도 했죠.

일찍 그리고 자주 실패하라 - 워드 커닝햄

그래서 저는 작은 단위로 일을 쪼개서 하고 피드백으로 자기 인식을 높혀 반복적으로 코딩하는 것이 더 나은 코드로 가는 길이라 믿습니다.
TDD의 리듬은 "정복하고 분할하라" 원칙 하에 같은 것을 여러 번 코딩하게 합니다.

리듬을 타기 위해서는 멈춰야 합니다.
리듬은 자신을 멈추게 합니다.
자주 멈추고 메타 인지를 높혀 다시 생각해 보아야 합니다.

<TDD> 에는 리듬이 그 역할을 하며
<TidyFirst?> 는 책 제목 스스로에게 질문이 그 역할을 합니다.
멈추고 모니터에서 자주 떨어져서 스스로에게 질문합니다.