와일드카드 임포트 (import *) 는 어쩌다 생겨나는가?
- JVM 계열 언어(자바, 코틀린) 을 쓰면 코드상에 의존하는 외부의 요소들은 import 로 명시를 해주게 됩니다
- 그래서 코딩을 하면서 import 문이 하나둘 늘어나다 보면
// 이렇게 하나씩 늘어나다가
import lotto.model.Game
import lotto.model.Issuer
import lotto.model.LottoWinners
import lotto.model.Rank
import lotto.model.Round
// * 로 퉁쳐버립
import lotto.model.*
- 위 코드처럼 * (와일드카드 심볼) 로 임포트 된 코드들이 되게 되는데요
- 특별히 옵션을 변경한적 없다면 5개 이상부터는 * 로 치환하게 되는데요, 그 이유는 인텔리제이 내장 포메터의 디폴트 동작 옵션이라 그렇습니다.
와일드카드 임포트 옵션 해제하는법 (Kotlin, Java)
Kotlin
- 우선 Kotlin 에서 와일드 카드 임포트를 방지하는 법 부터 알아보겠습니다
!
Java
와일드카드 임포트 도대체 뭐가 문제일까
- 대부분의 JVM 언어 기반 오픈소스나, 많은 기업들의 Springframework 코드를 작성하는 팀들에서 컨벤션으로
* import를 명시적으로 금지하고 있는거같습니다. - 아니 import 그까지꺼 그냥
* import하면 되지 뭐가 문제냐!! 할수도 있는데, 저도 실제로 왜 안되는지 궁금해서 찾아봤습니다.
1) 가독성 문제
- 코드가 길어질수록 *를 사용한 import 문은 코드를 읽기 어렵게 만들 수 있습니다. 다른 사람이나 나중에 자기 자신이 코드를 읽을 때, 어떤 클래스들이 현재 스코프에 있는지 명확하게 파악하기 어려울 수 있습니다.
- 여기에 대한 반론으로
* import를 하면 파일의 코드 라인도 짧아지니까 더 좋은거 아니냐? 말씀하실수도 있는데요- git PR 시에 어차피 diff 기준으로 PR 이 올라가기도 하고
네임 충돌 가능성: 서로 다른 패키지에서 같은 이름을 가진 클래스가 있다면, 와일드카드 import를 사용하면 충돌이 발생할 수 있습니다. 이는 예기치 못한 오류를 유발할 수 있습니다.
컴파일 시간 오버헤드: 모든 클래스를 import하면 컴파일 시간이 늘어날 수 있습니다. 컴파일러는 사용하지 않는 클래스까지 모두 확인해야 하기 때문입니다.
유지보수의 어려움: 다른 패키지에서 추가된 새로운 클래스가 현재 스코프에 영향을 미칠 수 있습니다. 코드를 변경하거나 업데이트할 때, 예상치 못한 문제가 발생할 수 있습니다.
결론
그냥 코딩 컨벤션 을 따르면 됩니다!
- 저의 경우에 부서에서는
import *을 허용해주는곳이고, 실제 대부분의 코드들은import *가 들어가 있는데요 - 대략 3년간 Live-service 를 제공하고 꽤나 규모가 큰 MSA 구조의 프로젝트인데도 import * 구문으로 인한 문제는 딱히 일어나지 않았습니다.
- 그래서.. 제 결론은 그냥 회사의 기존 코드베이스와 팀원들의 컨센셔스에 맞춰서, 그때그때 주어진 환경에서의 최선을 다하는데 중요할꺼같습니다.
- 개인적으로
import *를 허용하지 않는 옵션을 사용했는데, 제가 작성한 클래스파일을 다른 팀원이 수정하는 경우에import *로 수정해주시는 경우도 있어서 저도 컨센셔스에 맞추고 있습니다. - 그리고 사이드 프로젝트나 개인적으로 코드를 작성할때는 해당 옵션을 변경해서 나의 취향에 맞게 적절하게 상황에 따라 유연하게 사용하면 좋을꺼같습니다.