개발 slecs

확장자 목록 상수화로 공통 유틸 유지보수성 개선

목차

CommonUtil 리팩토링을 진행했음. 확장자 화이트/블랙리스트를 static final Set 으로 상수화.
변경 파일: 내부 클래스 1개

리팩토링 이유

기능은 잘 돌아가지만 코드 구조가 나중에 유지보수하기 어려운 상태였음. 특히 같은 로직이 여러 곳에 중복돼 있거나, 한 파일에 너무 많은 책임이 몰려 있는 경우가 있었음. 기능 추가나 버그 수정 시 여러 곳을 동시에 수정해야 해서 실수가 생길 위험이 높았음.

주요 변경

  • 중복 코드 추출 및 공통화
  • 역할별 파일/메서드 분리
  • 불필요한 의존성 제거
  • 가독성 개선

리팩토링 원칙

  • 동작은 바꾸지 않음: 리팩토링 전후 결과가 동일해야 함
  • 단일 책임(SRP): 각 파일/메서드가 하나의 책임만 지도록
  • DRY (Don't Repeat Yourself): 중복 코드 제거
  • 최소 변경: 필요한 곳만 건드리고 범위를 넓히지 않음

특히 인라인 JS를 외부 파일로 분리하면 브라우저 캐시 효과를 얻을 수 있어서 반복 방문 시 로딩이 빨라짐. 그리고 코드 리뷰나 검색도 훨씬 편해짐.

검증

리팩토링 이후 화면 동작이 기존과 동일한지 주요 케이스를 확인하고 커밋했음.

다음

작업 후기

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.

특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 함. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아옴.

개발 방식

  • 변경 전 현재 동작 스크린샷이나 수치 메모
  • 수정 후 같은 케이스로 확인
  • 관련 화면이 있으면 숫자 cross-check
  • 커밋 메시지는 "무엇을" 보다 "왜"를 담으려고 노력

작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉬움. 그래서 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중.

다음

댓글 0

첫 댓글 달아줘.