옛 거래소 시스템을 다시 만드는 일을 검토하면서 레거시가 무엇을 갖고 있는지 실사했다. 프로젝트 하나를 세니 소스 파일이 0개라 손대지 못한 껍데기로 분류했다.
Table of contents
Open Table of contents
크기가 안 맞은 껍데기
파일 수 0을 빈 프로젝트로 읽는 것이 앞서 배운 껍데기 함정과 같은 형태 아니냐는 지적을 받았다. 앞선 프로젝트에서 디렉터리는 있는데 내용이 스켈레톤인 것을 발견했었고 이번에는 반대 방향의 같은 실수였다.
다시 열어 디렉터리 크기를 보니 파일이 0개인데 14메가바이트였다. 파일 수와 크기가 안 맞으면 안을 봐야 한다.
IDE 캐시에 있던 실체
들어가 보니 IDE가 데이터베이스에 접속하면서 스키마와 루틴을 캐시해 둔 디렉터리가 통째로 커밋돼 있었다. 그 안에 SQL 파일이 291개였다.
저장 프로시저와 함수가 237개였고 접두로 나눠 세니 웹 서버용과 배치용과 지갑용과 거래소용으로 역할이 갈렸다. 주문 검증 프로시저 하나가 400줄이 넘었고 한국어 업무 주석까지 달려 있었다.
애플리케이션에 없던 규칙
이것을 알고 나니 다른 것이 설명됐다. 애플리케이션 소스가 1,200개 넘게 있는데 주문 검증 규칙을 아무리 찾아도 안 나왔던 이유가 거기 없기 때문이었다.
애플리케이션은 프로시저를 호출할 뿐이고 판단은 데이터베이스가 하고 있었다. 전수로 읽어도 안 나오는 것은 없는 것을 찾고 있었기 때문이고 안 나온다가 없다일 수 있다.
바뀐 과제
이 발견으로 재개발의 성격이 달라졌다. 컴포넌트를 새 언어로 이식하는 문제에서 업무 로직을 어디에 둘지 정하는 문제가 됐다.
데이터베이스에 남기면 이식이 적은 대신 특정 엔진에 묶여 배포와 판매 형태의 선택지가 좁아진다. 애플리케이션으로 올리면 237개를 다시 써야 하는 대신 자유로워진다. 어느 쪽도 쉽지 않지만 이것을 모르고 시작했으면 이식 도중에 발견했을 것이다.
실사 규칙과 뜻밖의 자산
같은 확인으로 옆 프로젝트 셋도 봤는데 그쪽은 디렉터리 트리만 있고 비즈니스 코드가 없는 진짜 스켈레톤이었다. 진짜 빈 것과 안 빈 것을 같은 방법으로 갈랐다.
실사 규칙으로 파일 수 0을 빈 프로젝트로 읽지 않고 크기와 안 맞으면 안을 보며 IDE와 빌드 캐시를 먼저 열고 안 나온다가 없다일 수 있다는 넷을 남겼다. 원래 커밋하면 안 되는 개인 설정 디렉터리가 유일하게 남은 로직 사본이었으므로 안 좋은 관행이 남긴 것도 실사에서는 자산일 수 있다.
정리
- 파일 수 0이 빈 프로젝트가 아니다
- 크기와 안 맞으면 안을 본다
- IDE와 빌드 캐시에 스키마와 루틴과 설정이 남아 있을 수 있다
- 업무 규칙이 애플리케이션이 아니라 데이터베이스 프로시저에 있을 수 있다
- 애플리케이션을 전수로 읽어도 없는 것은 안 나온다
- 안 나온다가 없다일 수 있으니 다른 계층을 본다
- 로직 위치를 알면 재개발의 과제 자체가 바뀐다
- 커밋되면 안 될 것이 유일하게 남은 사본이기도 하다