DLP 포털의 안 쓰는 PHP 파일을 정리하려는데 무엇이 안 쓰이는지 판단이 안 됐다. 경로와 클래스 이름을 문자열로 조립해 부르는 자리가 있었기 때문이다.
Table of contents
Open Table of contents
원인 — 조립된 경로는 검색에 안 잡힌다
require BASE_PATH . '/views/' . $name . '.php' 처럼 기준 경로에 이름을 붙여 읽는 코드와, $class = 'Handler_' . ucfirst($type) 처럼 접두어에 유형을 붙여 클래스를 만드는 코드가 섞여 있었다. 파일명이나 클래스명으로 grep 하면 그 자리가 안 나온다.
정적 검색이 못 보는 참조가 있으면 안 쓰인다는 판정 자체가 성립하지 않는다. 검색 결과가 없다는 것과 부르는 곳이 없다는 것은 다른 말이었다.
조치 — 실제로 읽은 것을 모으는 방법
정적으로 못 찾으니 돌려 보면서 실제로 읽힌 파일 목록을 남기기로 했다. 두 가지 방법이 있었다. opcache_get_status() 가 주는 scripts 목록을 주기적으로 받아 두는 것과, register_shutdown_function 에서 get_included_files() 를 로그로 흘리는 것이다. 뒤쪽을 골랐다. 이유는 PHP 매뉴얼의 설정 표에 opcache.enable_cli 기본값이 0 이라, cron 으로 도는 배치가 읽는 파일은 앞쪽으로는 안 잡혀서다.
며칠 모아서 find . -name '*.php' 전체 목록과 대조하니 한 번도 안 읽힌 것이 백여든 개 넘게 나왔다. 며칠로는 부족해서 한 달을 모았더니 그 수가 절반으로 줄었다. 월말 배치가 돌면서 여러 개가 잡혔으므로 얼마나 모아야 하는지는 그 시스템의 실행 주기가 정했다.
판단 기준 — 안 읽힘과 안 쓰임의 차이
남은 것을 하나씩 열어 보니 옛 기능 잔재와 시험용과 _backup 복사본이 대부분이었다. 그런데 정말 쓰는데 안 잡힌 것도 섞여 있었다.
views/error/500.php 처럼 특정 상황에서만 읽히는 파일이 그랬는데 그 기간에 그 오류가 안 났을 뿐이었다. 안 읽힌 것은 안 쓰이는 것이 아니라 그 조건이 안 일어난 것일 수 있다.
지우지 않고 옮기기
그래서 지우지 않고 _archive/ 폴더로 옮겼다. 읽으려 하면 require 가 실패하고 error_log 에 남으므로 그때 되돌릴 수 있다.
옮기기 전에 목록을 미리 알렸더니 분기 결산에 쓴다는 답이 와서 하나를 목록에서 뺐다. 알리지 않았으면 그 결산이 안 됐을 것이고 실행 기록만으로는 그 주기를 못 잡았다.
참조 그림이 드러낸 층
정리하면서 참조 관계를 층으로 그렸더니 어디를 고치면 무엇에 영향이 가는지가 보였다. 층을 건너뛰는 참조도 그때 드러났다.
CourseRepository 안에서 $_GET['page'] 를 직접 읽고 있어서 아래층이 위층의 것을 부르는 자리가 있었다. 정리하고 나서 얻은 것은 줄어든 코드 양보다 grep 결과가 깨끗해져 찾는 시간이 준 것이었다.
정리
- 경로나 이름을 조립해서 읽으면
grep으로 못 찾는다 - 검색 결과가 없다는 것과 부르는 곳이 없다는 것은 다르다
- 돌려 보면서
get_included_files()로 실제로 읽힌 파일을 모은다 opcache는 기본값에서 CLI 배치를 안 잡는다- 얼마나 모아야 하는지는 그 시스템의 실행 주기가 정한다
- 안 읽힌 것은 그 조건이 안 일어난 것일 수 있다
- 지우지 말고 옮기면 실패가
error_log에 남아 되돌릴 수 있다 - 옮기기 전에 목록을 알리면 아는 사람이 답한다
- 참조 그림을 그리면 층을 건너뛰는 자리가 드러난다