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