안드로이드는 1년 정도 개발하고 런칭 후에 

업데이트나 유지보수를 딴 사람한테 넘겨서

안 한지 1년 정도 됨

 

그래도 가끔 뭐가 추가되나 깃을 통해 확인하는데(사실 수용소에 올릴거리 있는지 찾아봄 머쓱;)

오늘 이런 환장할 코드가 생긴걸 확인했음

 

딱보면 이런 초보적인걸 실수?하나 하는 사람들이 있겠지만

아무 생각도 안 하고 이렇게 네이밍 하는 사람 은근 많음(나도 포함 머쓱;)

 

내가 이상한것 같다고 짚어줘도 사실 다 계획이 있는 코드일 수도 있고

내가 틀릴 수도 있지만 쨋든 이런 논의는 결론이 어떻든 항상 생산적이라고 생각해서

저는 시간날 때마다 팀원들 코드 봐주고 짚어주는 편임

 

자 그럼 뭐가 문제인지 짚어보고 어떻게하면 괜찮을지 생각해보자

 

 

 

첫째로 데이터 클래스의 프로퍼티 이름이 과도하게 지어진 것을 확인할 수 있다

 

이미 클래스의 이름이 StoreUserPaymentCardModel인데

프로퍼티의 접두사로 클래스의 이름을 다시 쓰고 있다

 

덕분에 프로퍼티의 이름이 storeUserPaymentCardSummary 이딴식으로 기본으로 20자가 넘어가서 가독성이 떨어지고

인스턴스화 시키고 프로퍼티에 접근하게 되었을 때는

 

 

이런 끔찍한 재앙이 일어나게 될 것이다!

별로 와닿지 않는가?

 

 

실제 이런 뺌꼬리 같은 코드를 줄줄이 적다보면 생각이 달라질 것이다.

마치

"""

대한민국 경기도 안산에 사는 프로그래머 이준영씨는 자리에서 일어났다.

대한민국 경기도 안산에 사는 프로그래머 이준영씨는 양치질을 하고 대한민국 경기도 안산에 사는 프로그래머 이준영씨는 아침을 먹고

대한민국 경기도 안산에 사는 프로그래머 이준영씨가 어제 산 양복을 입고 대한민국 경기도 안산에 사는 프로그래머 이준영씨의 직장으로 향했다....

"""

와 비슷한 코드다

 

그럼 알았으니 이제 좀 고쳐보자

StoreUserPaymentCard의 summary니까 프로퍼티이름을

storeUserPaymentCardSummary 에서 summary로 바꿔주면 좋을듯하다.(나머지도 똑같이)

 

 

이정도만 해도 훨씬 나아졌지만 나는 이정도도 번잡하다. 싶으면

kotlin에는 범위지정함수가 있는데

그걸로 더 간결하게 만들어보자

 

 

처음 코드에 비하면 훨씬 훌륭하다.

코틀린의 범위지정 함수는 우리팀은 사용이 능숙하고 눈에 익숙한 편인데

다른 안드로이드 개발자들 보면 안 쓰는 사람들도 꽤 있었다.

프로젝트를 같이 하는 팀원이 이런 문법에 익숙하지 않다면 안 쓰는 것도 고려해보자

오히려 더 헷갈리기만 한다.

 

 

 

둘째로 class이름이 좆같다

 

여기선 코드만으로 알기 어렵지만

이 데이터클래스는 매장페이지에서 사용자의 결제카드를 표시해주는 데이터의 model임

그렇다면 클래스 이름을 그냥 UserPaymentCardModel 혹은 payCardModel 이렇게 지어도 됐을텐데 왜 이렇게 길게 지었을까?

 

항상 변수나 함수, 클래스 이름이 길어지거나 뭔가 좆같아지면

저는 네임스페이스를 제대로 나누지 못했다고 생각함

말인즉 분명 클래스 이름을 StoreUserPaymentCardModel으로 지은 이유는

Store가 아닌 곳에서 UserPaymentCardModel을 표시해주는 일이 있었을것이고

분명 다른 곳에 MainUserPaymentCardModel 이딴식으로 페이지 이름을 접두사로 쓰는 클래스가 존재한다는 것을 유추할 수 있다.

그래서 똑같은 이름의 데이터클래스를 피하기 위해 페이지 이름을 접두사로 일일이 넣어주었을 것으로 예상된다.

(그게 아니라면 굳이 이름을 이렇게 길게 지을 이유가 있었을까?)

 

해결 방법은 두가지인데 

적당히 네임스페이스를 나눠서 data class가 사용되는 곳(이 경우엔 Store클래스가 되었다.)에서 innner로 선언해주어서

클래스이름을 UserPayCardModel 정도로 줄여주면 Store만 빼도 훨씬 간결하게 눈에 들어오는 것을 기대할 수 있다.

혹은 이러라고 만든건 아니긴 한데 코틀린이나 swift에서 typealias를 통해 특정 클래스에서 renaming해서 사용할 수도 있다.(근복적인 해결방안은 아님)

 

쨋든 네이밍과 네임스페이스를 잘 나눠주는 것은 10글자가 넘어가면 눈이 팽글팽글 돌아버리는 나에게는 너무 중요한 일이기 때문에

나의 코딩 시간은 많은 부분은 이름을 지을려고 생각하는데 소비되곤 한다. 그냥 영어가 딸려서 그런걸지도 모르고

 

 

 

셋째로 storeUserPaymentCardId가 var로 선언이 되어있는데

바뀔 일이 없기 때문에 val으로 선언해주는게 더 좋지 않았나..?

이 부분에 있어서는 var로 선언했을 때 치명적인 실수가 발생될 수 있는 상황이 그려지지 않아서

확답은 못하겠음

 

그외 이 코드만 봐선 알 수 없지만 

additionalSummaryId같은 경우에는 처음 로컬 DB에서 넘어왔을 땐 nullable하지만

로컬에서 첨 받아서 이 데이터 클래스로 넘겨주는 순간 null 체크로 null이면 공백문자가 들어가게 되어있는데

특별한 이유가 있나 하고 사용처를 확인해보니

뒤에서 결국 if payCardModel.additionalSummaryId == "" {} 이딴식으로 공백문자 체크하는거 보면

그냥 additionalSummaryId를 nullable타입으로 선언해주고 kotlin의 편한 null처리 연산자를 사용하는게 맞음

 

 

 

 

좆도 아닌 코드에 설명이 길어졌는데

이유는 항상 수용소에 올리는 문제는 읽는건지 마는건지 설명이 부족한건지 의견이 안 달리길래

확실히 이해해줬으면 해서 예시까지 좀 더 세세하게 써봤다

더 좋거나 다른 의견, 궁금증 혹은 "이 병신새끼 틀렸는데?" 하는 부분이 있으면 댓글로 막고라를 떠보자