1.
리팩토링을 해야 하는 이유에는 크게 두 가지가 있다. 성능 향상을 리팩토링과 가독성을 위한 리팩토링이다.
2.
두 가지로 분류하는 이유는 목적이 뚜렷해야 해야 할 일이 명확해 지기 때문이다. 무엇을 위한 리팩토링인지 정의하고 작업해야 한다.
3.
일단 성능 향상을 위한 리팩토링이 최우선이다. 가독성을 위한 리팩토링은 안 해도 개발자들이 불편한 것이 문제지만, 사용하는 사람이 불편한 소프트웨어는 당장 밥줄을 끊어 놓을 수 있다. (물론 가독성이 나쁜 소프트웨어가 성능도 나쁠 확률이 높다.)
4.
성능 향상을 위한 리팩토링 시 어느 구간이 성능을 떨어뜨리는지 파악해야 한다. API 호출 구간인지, BackEnd인지 DB인지 등.
5.
조사하다 보면 서비스 기능의 문제일 수도 있다. 불필요한 기능은 아닌지, 사용량이 낮은 기능은 아닌지, 기능을 다른 것과 통합할 수는 없는지. 그리고 기능의 제거나 통합과 관련해 기획팀이나 운영팀에 역제안을 할 수도 있다.
6.
성능 향상을 위한 리팩토링의 예시.
- 불필요한 API 호출: API 제거 또는 다른 API와 통합
- 대용량 데이터 조회: 조회 시 페이징 추가
- 낮 시간에 대량 스케쥴러 동작: 야간 또는 주말로 스케쥴러 실행 시간 변경
- 큰 사이즈 이미지 로딩: CDN 사용 또는 이미지 사이즈 줄여서 배포
- 업무 시간에 내부 인원의 대량 DB 조회: 서비스 이용량이 활발한 시간에 DB조회 금지 또는 내부용 DB 분리
- 과도한 DB 테이블 Join: 서비스 모델 분리 또는 Join 자제
7.
가독성을 위한 리팩토링은 내부 고객(=사내 개발자)과 신규 고객(=신규 입사자)을 위해 진행하지만 실질적으로 나를 위해 하는 것이다. 리팩토링할 코드를 가장 많이 다루는게 본인이기 때문이다.
8.
가독성 향상을 위한 리팩토링의 예시.
- 다양한 변수명, 함수명, 클래스명 사용: 코딩 컨벤션을 정해 일관된 명칭 사용
- 소스내에 반복되는 코드 존재: 함수로 분리
- 반복은 없지만 코드가 길어 가독성 해침: 함수로 분리
- 과도한 if else 사용: if else 사용 자제 또는 if else 안의 코드를 함수로 분리
9.
경험 상 성능에 영향을 미치는 건 DB 문제일 경우가 많았고, 가독성을 위해서는 함수로 분리하면 좋아졌다. 케이스 마다 해결책은 다를테니 리팩토링 경험이 개발팀내에 공유될 수 있도록 해야 한다. 개선의 관점에서는 FrontEnd, BackEnd 파트 구분이 없어야 한다.
10.
리팩토링을 한 번에 끝낸다는 생각은 틀렸다. 코드가 진화하고 있다면 리팩토링도 끊임없이 해야 한다. 시간이 날때 리팩토링을 한다고 생각하면 안 된다. 남는 시간이나 짧은 시간에는 단순한 수준의 리팩토링만 하게 된다. 일정을 분리해 리팩토링에만 집중하는 시간을 가지는게 좋다.
