Tidy First? Part 2. 관리

16장. 코드 정리 구분

• 코드 정리는 별도의 PR로 만들고, PR 당 몇 개의 코드 정리만 넣자
  • 순서가 있는 일련의 코드 정리는 하나의 PR로 만들자.
  • 동작 변경 역시 별도의 PR로 만들자.
• 작은 PR로 나누게되면 소소한 피드백을 유도할 수 있지만 무시될 우려가 있다.
• 작은 PR은 보통 검토 시간 단축되고 코드를 신속히 검토할 수 있어 동기부여가 될 수 이다.

17장. 연쇄적인 정리

코드를 계속 정리하고 싶은 충동을 관리하는 것도 코드 정리의 핵심 기술이다. 방금 정리 했는데 더 정리해도 될까? 상황에 따라 다르다.

먼저 작은 단계로 나누어 코드를 정리하는 방식을 사용하면서 최적화해보자.

다음과 같은 정리를 할 수 있는데 해당 내용은 이전 장의 내용을 참고하자.

• 보호 구문
• 안 쓰는 코드
• 대칭으로 맞추기
• 새로운 인터페이스로 기존 루틴 부르기
• 읽는 순서
• 응집도를 높이는 배치
• 설명하는 변수
• 설명하는 상수
• 명시적인 매개변수
• 비슷한 코드끼리
• 도우미 추출
• 하나의 더미
• 설명하는 주석
• 불필요한 주석 지우기

너무 많이 빠르게 변경하지 않도록 주의하자. 작은 정리를 순차적으로 하며 성공하는 것이 무리한 정리로 실패하는 것보다 시간을 아껴준다.

18장. 코드 정리의 일괄 처리량

통합과 배포를 하기 전에 코드 정리는 어느 정도 크기로 해야할까?

몇 가지 고려 사항이 있다.

• 코드 정리의 크기가 어느정도 되어야 쉽게 통합/배포를 할 수 있을까?
• 통합/배포 전 얼마나 많은 코드 정리를 해야 할까?
  • 다음 동작 변경을 지원하기 위해 얼마나 많은 구조 변경이 필요할까?

코드 정리의 범위를 판단할 때 고려할 만한 비용은 다음과 같다.

충돌

일괄 처리하는 코드 정리 작업이 많을수록, 통합 과정에서 지연 시간이 길어지고. 다른 사람의 진행 작업과 충돌할 가능성도 커진다.

충돌할 경우 병합하는 비용 또한 큰 폭으로 증가한다.

상호작용

다수의 코드 정리를 하다가 우연히 동적 변경을 할 수도 있다. (사이드 이펙트)
또한, 코드 정리 사이에 상호작용이 있으면 병합 비용이 커진다.

추측

한 번에 처리하는 코드 정리가 많을수록 더 많은 코드를 정리하게 된다. 이로 인해 추가 비용이 발생할 수 있다.

위 요인으로 인해 코드 정리 개수를 줄이는게 좋다.
하지만 많은 조직에서 하나의 변경 사항을 컴토하고 배포하는 데 드는 고정 비용이 상당히 많다.

코드 정리 비용을 줄이고자 한다면, 코드 정리 개수를 늘려서 동작 변경에 소용되는 비용을 줄이자. 그러면 검토 비용을 줄일 수 있다.

19장. 리듬

코드 정리를 관리하는 기술 중에는 정리의 리듬을 관리하는 일도 있다.

한 번의 코드 정리에 한 시간 이상이 걸리면, 이는 원하는 동작 변경을 위해 필요한 최소한의 구조 변경 시기를 놓쳤다는 의미일 수 있다.

하지만 코드가 너무 엉망이라면 동작 변경에 앞서 몇 시간을 들여서 코드 정리를 선행하는 것이 유리하다.

동작 변경은 코드 안에 뭉쳐서 나타나는 경향이 있다. 파레토 법칙에 따르면 80%의 변경 사항이 20%의 파일에서 발생한다.

코드 정리를 선행할 때 얻을 수 있는 장점은 코드 정리도 뭉쳐져 정확하게 동작 변경하기 좋은 위치가 될 수 있다.

코드 정리를 꾸준히 한다면 대부분의 변경 작업은 이미 정리된 코드 안에서 이뤄진다.

20장. 얽힘 풀기

코드의 동작을 변경하고 있는데 코드 정리를 해야 될 것을 알아 코드 정리를 진행했다고 가정해보자.

동작을 이제 변경하려고 보니 코드 정리해야 될 것이 추가로 생겼고, 정리한 코드가 변경할 동작과 얽혀 버렸다.

이럴 땐 진행 중인 작업을 버리고, 코드 정리를 선행하는 순서로 다시 시작해보자. 작업은 더 많아지지만, 이어지는 커밋과의 일관성은 분명해진다.

동일한 동작 변경을 하면서도 더많은 가치를 끌어낼 수도 있다.

21장. 코드 정리 시점

아예 안 한다면

코드의 동작이 앞으로 절대 바뀌지 않을 거라는 확신이 있으면 코드 정리를 할 필요가 없을 것이다.

나중에 정리하기

코드 정리를 아예 나중에 해도 무방하다.

코드 정리를 나중에 할 근거 중 하나는 학습 도구로 활용하는 것이다.

코드 정리를 나중에 자신이 원할 때 하면 더 의욕적이고 기분도 좋다.

동작 변경 후에 코드 정리

코드를 어떻게 정리해야 할지 당장 모르고 일단 코드 동작을 변경해보자.

동작을 변경했으니 코드를 정리해야 할까?

상황에 따라 다르다.

동작 변경을 한 코드를 대상으로 다시 동작 변경이 이뤄질 가능성이 크다면 코드 정리가 상당한 의미가 있다.

정리는 어느 정도나 해야 할까? 동작 변경에 한 시간이 걸렸다고 가정하면 한 시간 정도 코드 정리에 투자하는 것이 합리적이다.

다음과 같은 상황이면 동작 변경 후 코드를 정리하자

• 방금 고친 코드를 다시 변경할 예정일 때
• 지금 정리하는 것이 더 저렴할 때
• 코드 정리하는 데 드는 시간이 동작 변경에 드는 시간과 거의 비슷할 때

코드 정리 후에 동작 변경

코드 정리를 선행해야 할까? 이 역시 상황에 따라 다르다.

다음과 질문을 본인에게 해보자.

1. 지저분한 상태 그대로 코드 기반으로 동작 변경을 한다면 일이 얼마나 더 어려운가?

   • 코드를 정리한다고 해서 더 쉬워지지 않는다면 먼저 정리하지 말자

2. 코드 정리의 이점을 바로 얻을 수 있는지?

   • 예를 들어 코드를 정리하고 더 빨리 이해할 수 있다면 정리하자.

3. 코드 정리에 드는 비용을 어떻게 보상받을 수 있을까?

   • 코드를 딱 한 번만 변경할 예정이면 코드 정리는 제한하는 것이 좋다

4. 코드 정리에 얼마나 확신을 하고 있는가?

일반적으로 코드를 먼저 정리하는 것이 선호되지만, 정리 그 자체를 목적으로 삼지 않도록 경계해야 한다.

다음과 같은 상황에서 코드 정리 후에 동작을 변경해보자.

• 코드 정리를 했을 때, 코드 이해가 쉬워지거나 동작 변경이 쉬워지는 즉작적인 효과를 얻을 수 있을 때
• 어떤 코드를 어떻게 정리해야 하는지 알고 있을 때