저자가 언급한 ‘볼썽사나운 모습’에서 기술적인 관점과 인간적인 관점을 동시에 다루고 있다고 느꼈습니다. 동작 변경과 코드 정리가 뒤섞인 상황은 기술적인 혼란스러움을, 그 속에서 팀원 간 부족한 신뢰로 인해 불평을 늘어놓는 인간적인 혼란스러움을 전달하고 있습니다. 특히 인간적인 면에서의 혼란스러움을 느꼈던 것은, 저자의 다른 저서인 XP(익스트림 프로그래밍)에서 다룬 인간성이 떠올랐기 때문입니다. 소프트웨어는 사람이 만드는 것이고, 보통의 경우 혼자 만드는 것이 아니기 때문에 인간성에 기반한 협업을 해야 겠다는 생각을 했습니다.

변경은 변경을 낳는다는 말에 공감 했습니다. 그리고 이런 연쇄 변경에 대해 두 가지 생각을 했습니다.

하나는 연쇄적으로 발생하는 변경이 지금 당장 애플리케이션 동작에 영향을 주지 않는다면, 적정 수준에서 멈춰야 한다는 것입니다. 사람의 행동에도 관성이 있다고 생각 합니다. 현실적인 상황을 고려해서 적정 수준에서 멈출 수 있는 통찰을 가져야 겠습니다. 동료와의 관계도 tidying 해야지, 너무 많은 변화는 급하게 먹은 밥 처럼 급체할 수 있습니다.

다른 하나는 필요한 연쇄 변경에 대해 심리적인 안정감을 가지려면, 충분한 테스트 코드가 있어야 겠다고 생각 했습니다. 충분한 의미 있는 테스트 코드는, 특히 코드 정리를 할 때 진가를 발휘 한다고 생각 합니다. 왜냐하면 코드 정리는 원칙적으로 동작에 영향을 주면 안되기 때문에, 테스트가 실패하지 않는다는 것으로 동작에 영향을 주지 않았음을 확신할 수 있기 때문입니다.

PR의 적절한 크기와 구성(동작 변경과 코드 정리)에 대해서는 팀이 처한 상황과 코드에 대한 이해도 등을 고려해야 하며, 이 과정에서 합의가 이뤄져야 합니다. 아무리 어려운 것도 알면 쉽고, 아무리 쉬운 것도 모르면 어렵습니다. 이것 역시 인간성과 신뢰에 기반해야 동료 간 오해 없이 납득할 수 있는 건강한 리뷰를 할 수 있겠다고 생각 했습니다.

함께 일하는 환경에서 tidy first를 적용하려면 코드 정리를 구분 할 필요가 있다

2부 관리

Tidy First 에 물음표가 있다는 사실을 인지한 순간입니다.

이 책의 제목은 물음표가 강조된 제목입니다. 코드 정리법을 적용할 수 있다고 해서 반드시 코드를 정리해야 한다는 뜻은 아니라는 점을 강조하고 싶었습니다. - p.69

코드 정리법을 적용할 수 있다고 해서 반드시 코드를 정리해야 한다는 뜻은 아니라는 점을 강조하고 싶었다는 의미를 알아가면 좋을 것 같습니다.

16장 코드 정리 구분

켄트 백은 동작 변경과 구조 변경을 PR 단위로 나누자고 말합니다.

실무에서 도입에 성공하지 못한 경우라서 어떻게 실무에 적용해볼 수 있을지 궁금합니다.

실무에서 도입에 성공하지 못했던 이유를 생각해 보면 사전에 동작 변경과 구조 변경을 나눠서 계획한 경우가 없었고, 동작 변경을 하면서 구조변경이 필요하다는 것을 인식한 경우가 대부분 이었기 때문입니다.

그리고 동료 개발자 분들과 의미있는 PR 그리고 리뷰하기 좋은 단위 PR에 대해서 이야기를 나눠 보면, 이상적으로 동작 변경과 구조 변경이 나눠지는 것이 PR 리뷰의 효율을 높인다는 것에는 대부분 공감을 했지만, 실제 작업할 때 그 효용성을 느껴본 적이 없기 때문에 막연하게 시도하기 어려운 것도 있었습니다.

그래서 다음 인용문은 한번 해보고 싶은 욕망이 있는 환경 입니다.

코드 정리에 익숙해지고, 작은 단위로 작업하고, 절대적으로 안전하게 작업하는데 익숙해지면, 용기를 내서 코드 정리 PR을 따로 검토하지 않는 시도를 해 보세요. 그러면 대기 시간이 추가로 줄어들어, 더욱더 작게 PR을 만들도록 장려하는 효과가 생길 겁니다. - p.74

동작 변경과 구조 변경은 구분 되어야 한다

이 챕터를 보며 과거의 제 업무 방식이 생각났습니다 ㅎㅎ
클린 코드에서 배운 스카우트 규칙을 지키기 위해, 모든 동작 변경 영역에서 구조 변경이 함께 일어났습니다. 가끔은 지나가는 길에 본 구조 변경 대상도 덩달아 함께 변경되었습니다.

테스트 코드가 잘 되어 있었기 때문에 자신 있게 변경했었고 손쉽게 검증했었습니다.
굉장히 효율적으로 좀 더 좋은 코드로 한 발자국씩 나아가고 있다고 생각했고 실제로도 그러긴 했습니다 ㅎㅎ

다만 PR 사이즈가 정말 컸습니다. 뭐든 하나 PR이 나오면 수십 개의 변경이 동반되었습니다.
처음에는 그나마 커밋이라도 유의미하게 나눠왔습니다만, 다들 File Changed만 보고 리뷰하는 것을 보고 나중에는 커밋도 큰 덩어리로 만들곤 했습니다.

리뷰어는 정말 힘들었을 것 같습니다.
이 변경은 도대체 뭐가 동작 변경이고 뭐가 구조 변경인지 알기 너무 어려웠을 것 같습니다.
큰 사이즈에 압도 당했을 것 같습니다.
효율적으로 업무를 수행하기 위해 필요한 것들은 제대로 몰랐던 것 같습니다.

이제는 변경에 섞여 있는 동작 변경과 구조 변경을 구별할 수 있습니다.
그러면 책에 나온 것처럼 순서를 부여하고 PR을 나눠서 유려하게 작업할 수 있을까요?

그건 또 아닐 것 같습니다.

과거에 왜 PR이 점점 더 커졌는지 생각해 보면, 리뷰를 받는게 어려웠고 느렸던 것 같습니다. 어떻게 해서든 한 번에 많은 것들을 승인받아야 했습니다. 작고 잦은 변경은 사치였습니다.
작은 PR과 큰 PR의 장단점을 이야기 나누고 선택할 수도 없었습니다.

조직이 바뀐 지금은 다른 문제가 있습니다. main 브랜치로 머지 되기 위해선 변경에 대한 목적이 있어야 하는데 코드 정리는 그 대상이 되기 어려워 보입니다. 켄트백이 말한 구조 변경에 대한 리뷰 생략은 더욱 엄두가 나지 않습니다.

결국 지향 하고자 하는 것들은 환경과 문화가 뒷받침되어야 합니다. 켄트백의 철학에 공감할 수 있어야 합니다. 어서 2권이 나와서 이런 부분에 대해서도 지침을 주었으면 합니다 ㅎㅎ

소프트웨어 설계와 인간 관계 그리고 자기 관리

16장에 들어가기 앞서 'PART 02 관리'를 소개하는 문장을 만납니다.

코드 정리는 여러분에게 초점은 둔 소프트웨어 설계입니다. 그래서 여러분과 코드와의 관계 그리고 궁극적으로는 여러분 자신과의 관계를 다룹니다.

켄트 벡은 PART 2를 시작하며 PART 1에서 다루었던 코드 정리를 '관계'로 설명하고 있습니다.
관계라는 말이 어떤 분들에게는 다소 쌩뚱 맞다고 느껴질 수도 있지만
저는 이 책에서 말하고자 하는 핵심이라고 생각합니다.

그가 '들어가며' 에서 언급한 부분과 ByteByteGo 인터뷰에서 언급한 내용을 보면 일관적으로 소프트웨어 설계와 인간관계 연결하고 강조하고 있다는 사실을 알 수 있습니다.

소프트웨어 설계는 인간관계 속에서 벌어지는 활동입니다. - TidyFirst? 들어가며

우리가 열심히 노력해서 얻은 모든 기술적 전문 지식은 소프트웨어 개발을 둘러싼 관계에 도움이 되지 않는다면 아무소용이 없습니다. ... 관계 기술로서의 소프트웨어 디자인에 주목할 것 - ByteByteGo 인터뷰 중

@[yeTi] 예티 님이 지난 토론에서 다른 사람에게 소프트웨어 설계를 인간 관계로 설명한다면 상대가 이해하기 못 할 것 같다는 취지의 말씀을 하셨습니다.
좋은 지적입니다. 당시 저는 내가 이해한 것을 상대에게 단순하기 말하기 보다 상대의 맥락에 맞게 상대에 성향(예를 든다면 MBTI)에 따라 내가 이해한 소프트웨어 설계를 다르게 설명해야 그 사람에게 다가갈 수 있다고 말했습니다.
결론은 내가 아니라 나와 그 사람과의 관계 속에서 고민해야 한다는 것입니다.

다시 소프트웨어 설계와 인간 관계라는 주제로 돌아와서
인간 관계라고 하면 흔히들 사람과 사람 관계를 떠올립니다.
코드 정리라는 맥락으로 좁여보면 켄트 벡이 말하듯이
나 자신과 코드와의 관계를 뜻합니다.
그래서 코드 정리를 '괴짜의 자기 관리'라고 말하고 있습니다.

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

'자기 관리'라는 말에 또 다시 혼란을 느끼는 분들이 있을 듯 합니다.
<TidyFirst?> '들어가며' 에는 아래와 같은 문장이 있습니다.

이 책에서는 거울 속의 사람 즉, 프로그래머 자신과의 관계를 다루기 시작합니다.

켄트 벡과 옮긴이의 대화에서 알 수 있듯이 여기서 거울 속의 사람은 나 자신을 뜻합니다.
매 순간 코드 정리를 할지 말지는 다른 사람이 결정하는 것이 아닙니다.
나 자신이 결정하는 것이죠.
그렇기에 코드 정리가 나 자신과 코드와의 관계 속에서 발생하는 문제이며 자기 관리인 것입니다.

켄트 벡은 책에 제목에 물음표를 강조합니다.

이 책의 제목은 물음표가 강조된 제목입니다. 코드 정리법을 적용할 수 있다고 해서 반드시 코드를 정리해야 한다는 뜻은 아니라는 점을 강조하고 싶었습니다.

로버트 마틴이 말하는 보이스 카웃 규칙 처럼 코드 정리를 기계적으로 할 수 있습니다.
그런데 왜 물어야 하는 걸까요?
다시 책 <TidyFirst?> '들어가며'를 살펴보죠.

저는 매시간 "코드 정리가 먼저인가?"라는 질문에 대해 논의하면서, 그 해답을 찾았습니다. 그 논의를 통해 설계자로서 제 마음에 소중한 많은 주제를 다룰 수 있었습니다.

저는 대부분의 사람이 질문을 받으면 생각하고 답변하도록 프로그래밍되어 있다고 생각합니다.
규칙은 행동하게 하지만 생각하게 만들지 않습니다.
질문은 생각하게 만듭니다.

눈 앞에 보이는 코드가 있습니다 그리고 거울 속의 내가 있습니다.
그 관계에서 질문을 합니다.

Tidy First?

그리고 질문은 소프트웨어 설계에 대한 사유의 촉매제가 됩니다.

마지막으로 기억해야 합니다.
이러한 변화는 거울 속에 비친 나 자신으로 부터 시작해야 하고
항상 그리고 반드시 점진적이어야 하며, 작아야 하고, 일이 되어서는 안됩니다.

변경을 동작과 구조를 구분해서 인식하기

이 시점에서는 아직 계획도 없고, 바뀌는 동작 변경과 구조 변경 사이에 어떤 흐름도 없습니다. 서로 다른 두 가지가 함께 작용하고 있다고 이제 막 인식했을 뿐입니다.

저는 변화의 시작을 인식이라고 믿습니다.
그렇기에 인식하지 못하면 변화는 요원하기만 할 뿐입니다.

공통 흐름을 알아채면 동작 변경이 훨씬 쉬워진다

이 과정이 조금 지나면 공통 흐름을 알아차리기 시작합니다. 비슷한 코드끼리 정리하면 설명하는 도우미가 드러나고, 설명하는 도우미를 만들면 이어지는 동작 변경이 훨씬 쉬워집니다.

얼마 전 코딩을 하면서 겪었던 일 입니다.
변경이라는 일을 동작과 구조 변경으로 인식하게 되면서
동작 변경 후에 다음 동작 변경하기 전에 구조 변경을 하는 것이 좋겠다는 판단을 했고
구조 변경을 한 후에 동작 변경을 했더니 코드가 간결해져 코드가 줄어든다는 사실을 깨달았습니다.
코드 정리 후에 영향을 받을 다음 동작 변경이 다른 식으로 보이기 시작했습니다.

이렇게 하면 프로그래밍이 체스와 비슷해져서 게임이 어떻게 전개될지 보이고, 몇 수 앞을 짐작할 수 있습니다.

변경을 나누어 별도의 PR로 만들기

코드 정리와 동작 변경 사이를 번갈아 가면서 전환할 때마다 새 PR을 열어야 합니다.

기능 개선과 구조 개선에 대한 PR이 구분될 수 있는가? 에서 옮긴이에게 메일을 보내신 분의 고민하고 연결되네요.
앞선 댓글에서 제가 언급했지만
켄트 벡은 책 전반에 걸쳐 소프트웨어 설계를 인간 관계 속에서 벌어지는 활동이라고 정의하고 있습니다.
3장 대칭으로 맞추기에서도 언급한 것과 같이
저는 소프트웨어 개발이라는 활동이 유기적이라고 믿습니다.

코드는 마치 유기체처럼 성장합니다. 물론 일부 사람들은 '유기적'이라는 말을 경멸하기도 하지만, 제 생각은 다릅니다. 필요한 모든 코드를 한꺼번에 작성할수는 없는 없으니까요. 그것은 아무것도 배우지 못했을 때나 호언장담할 수 있는 일이죠.

조직 마다 PR 문화가 다릅니다. 심지어 코드 리뷰어 성향에 따라 달라집니다.
그래서 저는 이 말을 고지 곧대로 실천하기 보다 내가 속한 맥락, 인간 관계 속에서 고민하고
나만의 방식을 찾아 실천해야 한다고 생각합니다.
다른 사람 말에서 정답을 찾을 수는 없습니다. 그것이 심지어 켄트 벡이라도 말이죠 :)
다만 그는 당부의 말도 써 두었습니다.

이렇게 PR을 나눌지 또는 한 개의 PR로 처리할지 장단점이 있는 선택입니다. 무엇이 더 이로울지 생각해 보세요.

어떻게 하면 내가 속한 맥락에서 인간관계에서 내 방식을 찾을 수 있을까요?
다시 켄트 벡이 ByteByteGo 인터뷰에서 했던 말을 곱씹을 필요가 있습니다.
바로 '효율성'입니다.

핵심은 작업을 더 효율적으로 만드는 새로운 기능을 실험하고 찾는 것입니다.

무엇이 나에게 효율적인지 날마다 실험하고 개선해 나아가는 것입니다.

컴퓨터 마우스, 그래픽 사용자 인터페이스 등 고안자로 유명한 더글러스 엥겔바트는 작업을 세 가지 수준으로 구분합니다.

• A 작업은 원래 그 조직이 하기로 되어 있던 일을 하는 것
• B 작업은 A 작업을 개선하는 것
• C 작업은 B 작업을 개선하는 것

피터 센게는 더글러스 말을 인용하며 아래와 같이 말했습니다.

하지만 가장 미묘하고 또 잠재적으로 가장 영향력이 큰 것은 C 작업으로, 이는 우리의 사고방식과 상호 작용 방식을 개선한다. 궁극적으로 C 작업의 품질이 우리가 설계하는 시스템과 프로세스의 품질을 결정짓고, 나아가 우리가 제공하는 제품과 서비스의 품질을 결정짓는다.

인간 관계에서 신뢰를 쌓아 속도를 높여라

코드 정리에 익숙해지고, 작은 단위로 작업하고, 절대적으로 안전하게 작업하는데 익숙해지면, 용기를 내서 코드 정리 PR을 따로 검토하지 않는 시도를 해 보세요. 그러면 대기 시간이 추가로 줄어들어, 더욱더 작게 PR을 만들도록 장랴하는 효과가 생길 겁니다.

정당성의 원칙

권위를 가진 사람이 다른 사람들이 질서 있게 행동하기를 원한다면 이는 그 무엇보다도 먼저, 권위를 가진 사람들이 어떻게 처신하느냐의 문제인 것이다.

이를 ‘정당성의 원칙’이라고 하며, 정당성은 세 가지 원칙에 바탕을 둔다. 우선, 권위를 따르도록 요청받은 사람들은 자신에게 발언권이 있다는 생각, 다시 말해 그들의 목소리를 내면 상대는 들을 것이라는 생각을 가져야 한다. 둘째, 법은 예측할 수 있어야 한다. 내일의 규칙이 오늘의 규칙과 대략 같은 것이라는 합리적인 예측이 되어야 한다. 그리고 셋째, 권위는 공정해야 한다. 한 집단을 다른 집단과 차별 대우해서는 안 된다.

• <다윗과 골리앗> 259쪽