(번역) Bad Kotlin Extensions

원문: https://krossovochkin.com/posts/2021_01_25_bad_kotlin_extensions/

이 글은 위 글을 번역/요약한 글로, 모든 저작권은 원문의 저자인 Vasya Drobushkov에게 있습니다.

개요

Kotlin 익스텐션은 멋진 기능이다. 하지만 일부 개발자는 해당 기능을 과도하게 사용하여 익스텐션 함수가 없는 것보다 코드를 더 나쁘게 만드는 경향이 있다. 이 글에서는 Kotlin 익스텐션을 작성하지 않는 방법에 대한 몇 가지 예를 살펴본다.

우선, 우리는 좋은 익스텐션이 무엇인지 정의하려고 노력해야 한다.

모호하지만 간단하다. 좋은 익스텐션은 문제를 해결한다. 코드를 작성할 때에는 가독성을 향상시키는 역할을 하기도 한다. 익스텐션 함수는 첫 번째 매개변수가 익스텐션의 수신자인 정적 함수다.

예를 들어 다음과 같다:

익스텐션을 사용하면 first()라는 함수를 사용하기 위해 CollectionUtils를 들여다볼 필요가 없다. 굳이 Utils 클래스를 찾아보지 않도록 해당 객체에서 필요한 작업을 할 수 있도록 IDE가 자동 완성해준다.

자, 그럼 어떤 익스텐션이 나쁜 익스텐션으로 간주되는지 알아보자.

참고로 이 글에서는 일반적으로 프로젝트 내에 존재할 수 있는 public 익스텐션임을 기준으로 말하고 있다. 비공개 익스텐션 함수의 경우 대부분 큰 문제가 없다고 생각한다.

나쁜 익스텐션 종류

너무 똑똑함(Too smart)

예를 들어서 다음 함수가 있다고 하자.

“이걸 더 짧게 바꿔볼까?”

덕분에 !5 로 짧게 사용할 수 있게 되었지만 한 가지 문제가 있다. 다른 사람이 해당 익스텐션이 무슨 역할을 하는지 직관적으로 파악하기 어렵다는 것이다.

이름보다 더 많은 일을 함(Doing more than name says)

다음은 fragment를 replace하는 로직이다.

익스텐션으로 바꿔보자:

언뜻 보기에는 괜찮아 보이지만 문제가 있다. 위의 코드는 fragment를 replace 하는 것 뿐만 아니라 addToBackStack함수도 호출한다. 추가적인 동작 및 Side effect에 대해서 사용하는 사람이 잘 알지 못할 수도 있으므로 다음과 같이 만들어야 한다.

너무 구체적임(Too specific)

(바로 이전 예시에 이어서) 문제가 하나 더 있다면 너무 ‘구체적’이라는 것이다. 예를 들어 fragment를 add 하는 로직을 하나 더 만들어야 한다면 비슷한 함수를 하나 더 만들게 된다. 만약 commitAllowingStateLoss 옵션을 줘야 한다면? 또다른 함수를 만들거나 flag 파라미터를 하나 더 만들어야 할까?

다음과 같이 사용해보자:

훨씬 유연해진다. setReorderingAllowed를 호출하기 때문에 명시하지 않은 일을 한다고 생각할 수도 있지만 꼭 불러야 하는 메소드이고 inTransaction 익스텐션을 호출함으로써 우리는 장황한 솔루션을 가지고 잊지 않을 수 있다.

조금의 코드 분리 (Saving few characters)

다음 예시를 보자:

“ ::class.java 가 반복되면 못생겨질 것 같은데 익스텐션으로 만들어볼까?"

이제 못생긴 콜론을 사용하지 않아도 된다! 하지만 이걸 결과적으로 더 나은 코드라고 말할 수 있을까?

이 익스텐션은 쿨하고 자연스러운 Kotlin 코드처럼 보일 수 있지만 결과적으로 ‘코드 베이스를 개선했다’고 말하기는 어렵다. 따라서 이 익스텐션은 좋지 않다.

커먼 클래스에 있는 익스텐션 (Extension on common classes)

다음 코드를 보자:

이렇게 프로젝트단에 종속된 익스텐션은 해당 타입의 namespace를 오염시킬 수 있다. 타입과 직접적인 연관이 있지 않다면 익스텐션 함수를 만드는 것은 지양하라.

예를 들어 다음과 같은 익스텐션 함수는 만들어도 괜찮다:

요약

익스텐션 함수를 만들 때 어떤 문제를 해결하려고 하고 있고, 어떤 대안이 있는지 생각하는 것이 중요하다. 익스텐션 함수를 사용할 때 팀에 얼마나 큰 가치를 줄 수 있는지를 생각해야 한다.

Happy coding.