16. 코드 정리 구분
코드 정리 후 pr 시 발생할 수 있는 갈등 상황
- 동작 변경 코드 + 코드 정리 -> 커밋
- 검토자의 입장에서 pr이 너무 길다고 느낄 수 있음
- 동작 변경 코드 / 코드 정리 -> 분리 후 각각 pr
- 검토자 입장에서 코드정리 pr의 의미를 모를 수 있음
- 반복
코드정리를 안 하지 않는 이상, 코드정리는 어딘가에서는 처리해야 한다.
요약하자면, 코드 정리는 별도의 PR로 만들고, PR 당 몇 개의 코드 정리만 넣자.
코드 정리 구분
코드 정리에 대해 배울 때, 아래와 같은 예상되는 단계를 거칠 수 있다.
(B=동작변경, S=구조변경)
- 다양한 변경 필요성을 구분하지 않은 상태에서 변경 시도
- 동작변경인지, 구조변경인지 구분하지 않은 상태
- 동작 변경과 구조 변경
- 동작변경인지, 구조변경인지 구분한 상태
- 아직 어떤 흐름이나 순서는 없음
- 순서를 부여한 동작 변경과 구조 변경
- 비슷한 코드끼리, 비슷한 변경끼리 순서를 부여할 수 있음
- [BSSBSSSBBS] <- 이런 느낌
- 아직 큰 PR 하나에 묶여있는 상태
- 별도의 PR에 포함된 동작 변경과 구조 변경
- 묶을 수 있는 변경에 대해서 작은 PR로 쪼개기
- [B / SS / B / SSS / BB / S]
- 작은 pr은 검토 시간 단축으로 이어지고, 코드를 신속히 검토할 수 있도록 함
물론 위의 과정에서 4번이 꼭 정답은 아니다. 작은 PR은 소소한 피드백을 유도할 수 있지만 무시되는 가능성도 존재한다.
느낀점
최근까지도 pr 단위를 너무 크게한 것에 대해 의구심이 있었지만, 책을 보니 확실히 틀렸다는 것을 알았다.
현재 push 전 리베이스를 해서 커밋을 깔끔하게 정리하는 습관을 들이고있는데, 이것조차 3번 정도로 머물렀던 것 같다.
가급적 4번 pr을 쪼개는 방식을 사용해서 빠르게 검토받을 수 있도록 하자.
17. 연쇄적인 정리
코드 정리는 연쇄적으로 하게되는 문제점이 있다. 이러한 충동을 관리하는 것도 코드 정리의 핵심 기술이다.
먼저 작은 단계로 나누어 코드를 정리하는 방식을 사용하면서 최적화해보자.
가능한 정리 방식 (1장)
- 보호 구문
- 안 쓰는 코드
- 대칭으로 맞추기
- 새로운 인터페이스로 기존 루틴 부르기
- 읽는 순서
- 응집도를 높이는 배치
- 설명하는 변수
- 설명하는 상수
- 명시적인 매개변수
- 비슷한 코드끼리
- 도우미 추출
- 하나의 더미
- 설명하는 주석
- 불필요한 주석 지우기
주의점
- 코드 구조를 너무 대대적으로 바꾸려고 하지 않도록 주의
- 너무 많이 빠르게 변경하지 않도록 주의
- "작은 정리를 순차적"으로 하는 것이 "무리하게 하다 실패"하는 것보다 나음
18. 코드 정리의 일괄 처리량
통합과 배포를 하기 전에 코드 정리는 어느정도 크기로 해야 적절할까?
고려사항
- 코드 정리 (or 구조 변경) 양
- 코드 정리 크기
고려할 만한 비용
일괄 처리하는 코드 정리 수에 따라서 고려해야될 cost는 다음과 같다.
충돌
- 일괄 처리하는 코드 정리가 많은 경우 -> 통합 시 드는 시간 증가, 다른 사람의 작업과 충돌 가능성 증가
상호작용
- 일괄 처리하는 코드 정리가 많은 경우 -> 우연한 실수로 동작변경을 할 가능성 증가, 코드 정리 사이에 다른 작업과 상호작용이 있으면 병합 비용 급증
추측
- 일괄 처리하는 코드 정리가 많은 경우 -> 자연스럽게 더 많은 코드를 정리하게 됨
검토
- 일괄 처리하는 코드 정리가 적은 경우 -> 변경사항 검토 비용 증가 (여러번 PR, 여러번 검토)
- 일괄 처리하는 코드 정리가 많은 경우 -> 변경사항 검토 비용 감소 (한 번만 PR, 한 번에 큰 검토)
코드 정리 비용을 줄이고자 한다면, 코드 정리 개수를 늘려서 동작 변경에 소용되는 비용을 줄이자.
즉, 팀 신뢰를 바탕으로 코드 정리 후 검토하지 않는 것이 best
다만, 코드 정리 검토를 없앨 수준의 안전과 신뢰에 도달하는 과정 필요
- 여기서 신뢰는 cicd 툴에 대한것, 사람에 대한 신뢰 x
19. 리듬
한 번의 코드 정리에 한 시간 이상이 걸리면, 이는 원하는 동작 변경을 위해 필요한 최소한의 구조 변경 시기를 놓쳤다는 의미일 수 있다.
(물론 코드가 너무 엉망이면 오랜 시간을 쏟아서 코드 정리를 선행하는 것이 유리할 수 있음)
다행인 점은, 동작 변경은 코드 안에서 뭉쳐서 나타나는 경향이 있다.
- 코드 정리를 선행하면 코드 정리 내용도 뭉쳐짐
- 결과적으로 동작 변경하기에 가장 좋은 위치에 뭉쳐져 있음
- 즉, 코드 정리를 꾸준히 한다면 대부분의 변경 작업은 이미 정리된 코드 안에서 이뤄짐
- 따라서 정리되지 않은 코드를 만나는 일이 줄고, 코드 정리는 1시간 이내로 가능 (잘 된 경우에) - 응집도
20. 얽힘 풀기
코드 동작 변경 시 코드 정리가 얽히는 경우
- 코드 동작 변경중
- 코드 정리 포인트 발견하여 코드 정리 진행
- 다시 동작을 변경하려고 보니 코드 정리해야 될 곳이 추가로 생김
선택지
- 그대로 배포 (당장 처리 가능, but 검토 어렵고 오류 발생 가능)
- 코드 정리와 변경사항을 여러 PR 또는 여러 커밋으로 나누기 (검토 쉬워짐, but 작업횟수 증가)
- 진행 중인 작업 버리고, 코드 정리를 선행하기 (커밋 일관성 확보, but 작업량 증가)
세 가지 선택지 모두 매몰비용이 있지만, 3번을 고려하는 것이 생각보다 나쁘지 않다.
진행 중인 작업 버리고, 코드 정리를 선행하기
- 장점
- 커밋의 일관성을 확보
- 다시 구현하면서 새로운 가치를 끌어낼 가능성 존재 - 단점: 작업량 증가
21. 코드 정리 시점
정리하지 않기
- 앞으로 다시는 코드를 변경하지 않는 경우
- 설계를 개선하더라도 얻는 것이 없는 경우
나중에 정리하기
- 정리할 코드량이 많은데, 보상이 즉각적이지 않는 경우
- 코드 정리에 대한 보상이 잠재적인 경우
- 작은 묶음 여러 번에 나눠서 코드 정리를 할 수 있는 경우 (?)
동작 변경 후 코드 정리하기
- 다음 코드 정리까지 기다릴수록 정리 비용이 더욱 불어나는 경우
- 코드를 정리하지 않으면 일을 끝냈다는 느낌이 들지 않는 경우
코드 정리 후 동작 변경하기
- 코드 정리 시, 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉각적인 효과를 얻을 수 있는 경우
- 어떤 코드를 어떻게 정리해야 하는지 아는 경우
결론적으로 켄트 벡은 PR의 크기를 줄여 충돌이나 은연중 추가 되는 동작 변경의 위험을 줄이라고 말을 하면서 늘어나는 PR의 수는 팀의 신뢰도의 기반하여 구조변경 PR은 리뷰를 하지 않는 방향을 추천합니다.
