[의견대립] Dialog 확장함수를 어떻게 쓸 것인가
배경
프로젝트에서 AlertDialog가 많이 사용되는데 객체를 생성하는 부분은 공통이라 보일러 플레이트 코드가 된다. 이것을 지양하고 편의성을 높이고자 팀원이 확장함수를 만들어주었는데 코드는 아래와 같다.
이 확장함수는 하나의 xml만 inflate하고 그 안에 들어가는 text나 event를 dialog 객체 생성할 때 직접 입력해주는 식이다. 이렇게 하면 같은 layout일 경우에만 유용하고 조금이라도 수정 사항이 생기거나 새 디자인의 dialog가 추가되었을 때 커버할 수 없다.
따라서 나는 아래와 같은 확장함수를 직접 만들어주었다.
dialog의 디자인이 어떻든 xml만 잘 만들어서 inflate해주면 기존의 코드를 건드리는 일 없이 모든 경우를 커버할 수 있다. 기존 확장함수의 한계를 해결할 수 있는 코드여서 나는 당연히 팀원이 바로 수용을 할 줄 알았다. 그런데 팀원이 반대표를 던졌다.
대립점
xml 여러개 만드는 것보다 하나의 xml을 사용하고 분기 처리를 해주는 게 더 효율적인 방법이라는 것이 이유였다. 하지만 팀원이 제시한 근거가 나에겐 설득력 있게 다가오지 않았다.
왜냐하면 내 방법대로 하면 분기 처리를 안 해줘도 되고 모든 경우를 커버할 수 있는데 왜 굳이 불편하게 매번 분기 처리를 해줘야 하는 방법을 선택하는지 받아들이기 어려웠다. 우리가 다루는 dialog의 디자인이 다양함에 따라 분기 처리 코드도 지저분할 것 같았다. 그리고 하나의 xml을 쓰는 만큼 버튼 이름을 디테일하게 정할 수 없고 포괄적으로 정해야 한다.
가령 좌/우 버튼의 id값을 btn_no, btn_yes로 정한다면 왼쪽의 dialog에서는 어느정도 맥락을 이해할 수 있지만, 우측처럼 yes/no로 구분짓기 애매한 경우엔 btnYes.setOnClickListener{}가 실행됐을 때 '보관함 가기'가 실행되는 것인지 '바로 달리기'가 실행되는 것인지 직관적인 파악이 어렵다.
이런 문제점들이 있다고 전달했는데 팀원은 그러면 dialog 관련 확장함수를 여러개 만들자고 했다. 또 핵심적인 디자인이 아니라면 하나의 xml을 재활용할 수 있게 디자이너 팀원한테 수정을 요청하자고 했다.
나는 더 받아들이기 어려웠다. 보일러 플레이트를 줄이고자 확장함수로 만든 건데 같은 기능을 하는 것에 대해 여러 확장 함수를 만드는 건 중복 코드를 남발하고 확장함수 사용의 취지를 퇴색시키는 것이라고 느껴졌기 때문이다.
또한 개발 과정에서 디자인을 조율하는 건 얼마든지 있을 수 있는 일이지만, 내가 만든 확장함수를 쓰면 디자인 팀원들이 어떤 디자인을 요구하든 다 커버가 가능한데 분기 처리가 까다로워서 디자인 수정을 요청하는 것 자체가 한계가 있다는 반증이라는 생각도 들었다.
타협점을 찾기 위한 과정
우리는 각자의 방법이 best option이라고 확신하기 어렵기도 하고 더 좋은 방법이 있을 수도 있으니 여러 사람들의 의견들도 들어보기로 했다. 따라서 각자의 방법을 평소에 같이 공부하던 스터디원들에게 공유했다.
스터디원들 사이에서도 의견이 갈렸다. 그런데 결과적으로 도움이 되었다. "xml 하나만 두고 재사용하는 게 효율적이야"와 "비슷한 것들끼리 xml이 너무 많이 생기면 헷갈릴 수도 있을 것 같아"는 결국 서로 같은 입장인 건데 사람에 따라 다르게 표현됐고 이 표현에 따라 나에게 다가오는 설득력도 달랐다.
이렇게 듣고보니 내용만 다르지 구조가 같은 dialog가 6개나 되는데 이것들을 모두 개별 xml로 만들어주는 건 확실히 낭비라는 생각이 들었다. 하지만 수정이 일어나거나 새로운 디자인이 추가되었을 때 곧장 대응하기 어렵다는 한계는 여전했다.
의견 조율 완료
그래서 결국 팀원과 내가 내린 결론은, 팀원의 방법과 내가 만든 방법을 모두 유지하자는 것이었다. 앞으로 새 기능이 개발되면서 어떤 변화가 일어날지 모르지만 같은 구조의 dialog가 추가된다면 나도 팀원의 방법을 따라 리팩토링을 진행해서 적은 수의 xml로 관리를 하고, 기존의 dialog들과 겹치지 않는 새 디자인이 추가된다면 내 방법을 써서 유연하게 대응하기로 했다.