Tidy First?

 

 

켄트 벡의 새로운 책이 나왔다고해서 번역서가 나오기 전에 개발 관련 커뮤니티에서 화제가 되었다. 

켄트벡은 XP책에서 운전처럼 실전에서 배우는 것의 이야기를 한 적이 있다. 

 

제목은 Tidy First? 인데 ? 가 들어간 것이 재미있다. 

 

중의적 표현

• 정리할까?

내가 작업한 작업 내용이 어떤 내용일까?

• tidying? 기능개발?

 

왜 리팩터링이 아니고 Tidy 라는 표현을 썼을까. 저자는 작게 시도하는 것을 강조한다. 코드 정리는 1시간 내.

리팩터링은 좀 더 큰 개념이다. 리팩터링을 하는 과정에서 기능개발을 중단을 의미할 수도 있다. 

정리를 통해서 작게 진행하면 검토의 부담과 충돌 부담을 줄일 수 있다.

 

코드 정리 구분을 하면 4단계다.

1. 프로그래밍 처음에는 작동을 위한 변경사항을 잔뜩 만듦.
2. 코드 정리 작업. 구조적 변경, 행위적 변경. 한번에 하나씩만.
3. 어떤게 더 쉬워질까. 어떤 것들을 할까. sequence. 더 변경이 쉬워질까.
4. 작은 PR 만들어서 변경을 해보기. 행위변경과 구조 변경 두개를 하는 것은 아님.

책에서는 인간이랑 일하는 것을 많이 이야기한다. 인간관계의 사회적 활동.

요소들을 유익하게 관계 맺는 일 중 소프트웨어 설계자는 3가지만 가능하다.

1. 요소를 만들고 삭제

2. 관계를 만들고 삭제

3. 관계의 이점을 높임.

농서인 common culture에서 아이디어를 많이 가져왔다. 

 

IDEA → BEHAVIOR

구조가 행위에 시각적으로 보이는 것은 아님.

나중에는 행위를 바꾸기가 어려워짐.

 

기능변경은 돈을 벌 수 있는 기능 추가를 말하고

구조변경은 눈에는 보이지 않지만 변경을 수월하게하는 정리를 말한다. 

 

저자의 옵션 소개에서 통찰이 많이 나온다.

현재 소프트웨어가 하는일과 미래의 가능성으로 설계의 가치.

당장 얻을 수 있는 가치, 미래 가능성을 통해 코드 정리를 바로 할 것인지

나중에 할 것인지 정할 수 있다고 한다.

 

당장 얻을 수 있는 가치: 현금 흐름, 돈 벌기 가능한 기능 변경

옵션: 미래에 기능 변경 쉽게 코드 정리, 구조 바꾸기.

 

미래 가치를 위해서는 꾸준히 정리가 필요하다.

자주 변경될 수록

자주 읽을 수록 

복잡한 코드일 수록.

 

소프트웨어의 비용은 결합도가 영향을 끼친다를 주제로 설명한 것도 인상적이다. 

결합은 완전히 사라지는 것은 아니고 절충점을 찾아야한다는 것.