새 프로젝트에 들어갔는데 Laravel 코드가 이미 몇 년 쌓여 있고 문서는 없다시피 했다. 전부 읽는 것이 불가능하므로 어디부터 읽을지를 먼저 정해야 했다. 두 가지 방법이 있었는데 app/ 폴더 구조를 따라 위에서부터 읽는 것과 데이터와 실제 흐름을 따라 읽는 것이다. 뒤쪽을 골랐다. 이유는 폴더 이름이 몇 년 사이 실제 역할과 갈라졌을 가능성이 커서다. 대신 전체 지도를 그리는 데 며칠이 더 드는 것을 감수했다.
Table of contents
Open Table of contents
배경 — 데이터를 먼저 보는 이유
코드보다 데이터베이스를 먼저 봤는데 코드는 바뀌어도 데이터는 남기 때문이다. 지금 코드가 어떻게 생겼든 테이블 구조는 이 시스템이 무엇을 다루는지를 보여 준다.
information_schema.TABLES 의 TABLE_ROWS 로 행 수를 보고 큰 테이블의 컬럼과 외래키를 차례로 봤다. 행 수를 본 것이 의외로 유용했는데 200개 중 대부분이 수백 행이고 몇 개만 수천만 행이라 그 대여섯 개가 이 시스템의 중심이었다.
조치 — 안 쓰이는 진입점 걸러 내기
그다음 Laravel 공식 문서대로 php artisan route:list 로 라우트 목록을 뽑아 어떤 주소가 어느 컨트롤러로 가는지를 봤다. 여기서 access.log 와 대조하니 선언된 것 중 절반 가까이가 한 달간 호출이 0이었다.
실제로 도는 것부터 읽으면 되므로 읽을 범위가 크게 줄었다. 목록만 보고 전부 읽으려 했으면 안 쓰이는 코드에 시간을 썼을 것이다.
검증 — 한 흐름을 끝까지
여기가 핵심이었는데 여러 곳을 조금씩 읽는 것보다 하나를 끝까지 따라가는 편이 훨씬 나았다. 가장 중요해 보이는 흐름 하나를 골라 요청이 들어와서 나갈 때까지 전부 봤다.
라우트에서 Controllers 와 Services 와 Models 를 거쳐 데이터베이스까지 가고 중간에 외부 호출과 Event 로 갈라지는 것을 다 따라갔다. 그러니 이 코드베이스의 관례가 보였고 어디에 무엇을 두는지와 오류를 어떻게 다루는지와 이름을 어떻게 짓는지를 알고 나니 다른 흐름은 훨씬 빨리 읽혔다.
원인 — 이력과 오류가 알려 준 것
코드만 보면 왜 이렇게 됐는지를 모르므로 이상해 보이는 줄은 git blame 과 git log -p 로 봤다. 급하게 넣은 예외 처리와 넣었다 뺐다 한 흔적과 한 사람만 만진 부분이 나왔다.
세 번째가 중요했는데 여러 사람이 만진 곳은 어느 정도 정리돼 있고 한 사람만 만진 곳은 그 사람의 방식대로 돼 있다. 마지막으로 laravel.log 를 보니 상위 다섯 유형이 전체의 70퍼센트 정도였고 그 다섯이 나는 코드를 읽으니 이 시스템의 취약한 구조가 드러났다.
주의 — 하지 말았어야 한 것
이상해 보이는 코드를 처음부터 고치려 한 것이 실수였다. 몇 번 고쳤다가 되돌렸는데 왜 그렇게 돼 있는지 모르는 상태에서 고치면 안 된다는 것을 그때 배웠다.
이상한 코드에는 대개 이유가 있었고 이유가 사라졌는데 코드만 남은 경우도 있었지만 그것을 판단하려면 먼저 알아야 한다. 폴더 구조로 이해하려 한 것도 틀렸는데 폴더 이름이 실제 역할과 다른 경우가 많았고 Helpers/ 에 핵심 로직이 있기도 했다.
정리
- 데이터부터 보면 코드가 바뀌어도 남는 것이 보인다
- 행 수를 보면 어느 테이블이 중심인지 드러난다
- 진입점 목록과 접근 기록을 대조하면 읽을 범위가 줄어든다
- 여러 곳을 조금씩 읽지 말고 한 흐름을 끝까지 따라간다
- 그러면 그 코드베이스의 관례가 보인다
- 이상한 코드는 이력을 보고 한 사람만 만진 곳을 가려낸다
- 자주 나는 오류가 그 시스템의 약한 곳이다
- 왜 그런지 모르는 상태에서 고치지 않는다