코드 정리를 하면서 어디부터 손댈지 정해야 했는데 눈에 거슬리는 곳부터 고르는 대신 숫자를 먼저 내 보기로 했다.
Table of contents
Open Table of contents
여는 빈도 측정
반년치 커밋 이력에서 파일별로 수정된 횟수를 뽑아 정렬했다.
$ git log --since="6 months ago" --name-only --pretty=format: | sort | uniq -c | sort -rn | head -20
88 app/Services/OrderService.php
62 app/Http/Controllers/OrderController.php
41 app/Models/Order.php
1 app/Legacy/OldReportGenerator.php
0 app/Legacy/LegacyImporter.php자주 여는 것과 안 여는 것이 뚜렷하게 갈렸는데 한쪽은 반년에 88번을 열었고 다른 쪽은 반년에 한 번 열거나 아예 열지 않았다.
정리 대상의 우선순위
정리의 값은 그 코드를 얼마나 자주 읽는지에 비례한다. 88번 여는 파일을 읽기 쉽게 만들면 그 이득이 88번 나고, 아무도 안 여는 파일은 아무리 깔끔하게 만들어도 그것을 볼 사람이 없다.
그래서 가장 자주 여는 것부터 정리하고 반년에 한 번 여는 것은 손대지 않았다. 정리하고 싶은 코드와 정리해야 할 코드가 같지 않다는 것이 숫자로 갈렸다.
안 여는 곳의 처리
안 여는 곳은 정리 대신 다른 것을 했는데 구조는 그대로 두고 무엇을 하는 코드인지를 파일 맨 위에 적었다.
/* 2019 년 이관 때 쓴 것. 지금은 월 1회 배치에서만 부른다.
입력: 옛 시스템의 CSV. 출력: order 테이블
담당: 없음. 문제가 나면 배치를 멈추고 담당을 정한다 */담당이 정해져 있지 않다는 사실도 함께 적었고 반년 뒤에 그 파일을 열었을 때 읽는 시간이 실제로 줄었다.
안 여는 것 중에서도 도는 것과 안 도는 것을 갈랐다. 실행 로그에서 이름을 찾아 보니 하나는 로그에도 없어서 돌지 않는 코드였다. 그것은 보관 디렉터리로 옮기고 세 달 동안 아무 일이 없는 것을 확인한 뒤 지웠다.
고침 횟수와 참조 횟수
고치는 횟수와 다른 파일에서 참조되는 횟수를 따로 세어 보니 둘이 서로 다른 것을 가리키고 있었다.
파일 고침 참조
OrderService.php 88 41
OrderStatusEnum.php 2 62상태 열거형은 거의 안 고치는데 62곳에서 참조하고 있었다. 안 고치니 정리 대상은 아니지만 여기를 고치면 62곳에 영향이 가므로 조심할 대상이다. 자주 고치는 곳과 많이 참조되는 곳은 다른 이유로 중요하고 다른 방식으로 다뤄야 했다.
영역별 성격을 표로 만들어 두고 새로 합류한 사람에게 그 표를 먼저 보였다. 어디를 주로 보게 될지와 어디를 조심해야 하는지가 그 표에서 갈린다.
다시 열었을 때 읽을 것
정리를 안 하기로 한 곳에서 문제가 났는데 반년 만에 열었더니 무엇을 하는 코드인지 몰라 파악에만 하루가 걸렸다.
그 뒤로 안 여는 곳에도 최소한을 넣었는데 무엇을 하는지와 입력이 어디서 오는지와 실패하면 어떻게 되는지와 주의할 점 네 줄이다.
/* 이 파일은 자주 안 고친다. 고칠 일이 생기면 아래를 먼저 읽는다.
무엇: 월 1회 옛 시스템 CSV 를 읽어 order 에 넣는다
입력: /data/legacy/*.csv (매월 1일 상대가 올린다)
실패하면: 배치가 멈추고 알림이 온다. 재실행은 --date 로 그 달만
주의: 인코딩이 EUC-KR 이다 */네 줄을 적어 둔 것만으로 하루 걸리던 파악이 30분으로 줄었다. 정리는 안 하더라도 다시 열었을 때 읽을 것은 남긴다.
정리
- 자주 여는 곳과 안 여는 곳을 세어서 가른다
- 정리의 값은 그 코드를 얼마나 자주 읽는지에 비례한다
- 정리하고 싶은 코드와 정리해야 할 코드가 같지 않다
- 안 여는 곳은 정리 대신 문서화한다
- 안 열고 안 도는 것은 지우고 안 열지만 도는 것은 남긴다
- 고치는 횟수와 참조되는 횟수를 나눠 본다
- 많이 참조되는 곳은 고칠 때 영향을 확인한다
- 정리를 안 하더라도 다시 열었을 때 읽을 것은 남긴다