더 이상 실수하지 않기 위해 적어보는 리팩터링 방법

데이터베이스의 구조 변경이 많은 경우 

- 기존 데이터베이스는 꼭 dump 떠놓기 (테이블을 건들게 된다면 무엇을 하든 꼭 첫번째로 하자)

- 기존 컬럼(old column)은 유지하고 새로운 컬럼(new column)을 함께 만들기, 여기서 문제가 없음을 확인하면 조금씩 이전 컬럼 지워나가기

- 컬럼 몇개의 대체보다 더 큰 구조적 마이그레이션이 필요하다면 테이블 복제를 통해 새로운 테이블을 만들고 작업 후 테이블을 교체하기

  (기존 테이블에서 작업하다보면 이전 데이터를 날려버릴 수 있는 위험 상황에 놓일 수 있다..ㅎ)

 

API 의 버전 교체가 필요한 경우

- API 기존 버전도 여전히 동작 가능해야 한다. 해당 API를 사용하는 곳을 전부 추적하고 바꾸도록 요청할 수는 없기 때문에 기존 API도 동작 가능해야 한다.

- 여기서 어느정도 새로 만들어진 API가 안정이 되었을 때 이전 버전은 서서히 지워나가야 한다. (언제까지고 여러 버전을 동시에 지원하게 되면 문제가 발생했을 때 추적하기 어렵다.)

 

코드 리팩터링

- 동일한 동작을 하는 새로운 함수를 만들고 그 함수로 점진적으로 교체 (테스트코드도 함께)

  (이전 함수를 사용하는 코드가 더 이상 없다면 그 때 이전 함수를 제거)

- private 함수를 테스트하고 싶은 상황이라면 클래스를 분리하자.

 

 

아예 새로운 기능을 구현하는 것보다 기존 코드를 리팩터링하는게 훨씬 훨씬 어려운 것 같다..

데이터 마이그레이션을 하다가 이전 데이터를 날려버릴 뻔 한적이 있어서 같은 실수를 반복하지 않기 위해 겪은 문제들을 통해 깨달은 부분들을 작성하고 기억해나가려고 한다. 

추가적으로 더 생각나는게 있다면 계속적으로 추가해야겠다.