사실 이 패턴에 대해서 적으려고 한건 아니고
최근에 회사에서 비슷한 기능인데 조금씩 달라서 6개로 나눠져 개발된 레거시 코드를
통합, 재활용하고 관심사별로 깔끔하게 분리하는 작업을 진행했는데
생각보다 많은 고민을 하게 되면서 했던 생각들에 대한 기록이다.
처음에는 AI에게 통합을 위한 제안을 해보라고 했다.
그게 한번에 맘에 들었으면 내가 고민도 안했겠지.
아무리 코드베이스를 알아도 코드 컨벤션을 적어놓고 기존 코드방식을 참고하게 해도
방대한 코드와 히스토리를 전부 알지 못하는 AI는 우리 개발팀의 코드취향(?) 을 녹여내진 못했다.
우리 팀은 전체적으로 중복코드는 싫어하지만
재활용 코드가 방대해져서 오히려 발목을 잡는 코드들을
극도로 싫어하는 편이다. (잘못 만든 BaseActivity 같은 그런 것들...)
그럴빠에는 차라리 중복이 되더라도 깔끔하게 분리를 해버리자는 주의.
하지만 이번 개선작업에서는 모든 화면에 중복되는 기능이 꽤 많았다.
화면은 거의 흡사했고...
다만 같은 기능인데도 화면에 따라서 다르게 동작하는 케이스가 화면마다 각각 존재할 정도로
하나의 베이스로 다 묶어내기가 매우 곤란한 상황이였는데
그렇다고 진입한 화면에 따라 분기처리를 하는것도 팀장님께선 매우 싫어하셨기에
(분기가 늘어나기 시작하면 끝도없고 히스토리를 모르는 사람은 코드에서 헤맨다.
개발자가 신경 써서 개발해야하는 구조는 좋지 않은 구조라고 생각하신다. 나도 여기엔 동의한다.
그냥 설계만봐도 어디에 뭘 구현해야하는구나 이게 눈에 바로 들어오고 다른건 신경쓰지 않아도 되는
코드가 좋은 코드라고 생각한다.)
다른 설득 방법을 찾아야했다. (난 어떻게든 중복을 줄여서 만들어보고 싶었다..)
모든 화면에서 동일한 로직은 base로 빼면서도 각 화면이 본인에게 필요한 기능만 조립해서
자체 구현하게 하면 좋겠다 생각했다.
그냥 인터페이스에 다 때려박고 상속 받은 애들을 구현 강제화 할까도 싶었지만
그럼 또 구현이 필요없는 애들도 오버라이드는 해줘야하는게 꼴보기 싫었다.
비어있는 오버라이드 함수만큼 보기 싫은게 없음 ㅋ 추상을 쓰기에도 좀 애매했음
그래서 그냥 중복되는 함수들 말고는 다 각각의 인터페이스로 최소화해서 쪼갠뒤
인터페이스를 여러개 상속받아서 조립하는 방식이면 구현을 강제화 하면서도
불필요한 함수를 만들지 않아도 되는거 아닐까! 이런 생각을 했고
그렇게 구현해봤다.
결과가 꽤 흡족했는데 이런걸 무슨 패턴이라고 부르는게 있으려나 하고 찾아봤더니
제목의 Role interface 패턴이 라고 하는거였다 ㄷㄷ
개발자들이 역시 다 같은 고민을 했었구나 싶으면서도
나도 그런 생각을 같이 떠올렸고 같은 방향을 제안했다는게
흥미로웠다.
암튼 그랬다.
아 추가로 요즘은 브이로그를 쉽게 만들어주는 앱을 만들어보고 있다.
지금까지 내가 만든 앱들을 주변 사람들이 보면 좀 시큰둥한 반응이 많았는데
이번엔
"언제 출시하냐 출시하면 좀 알려줘라"
"테스터로 써볼 수 있음?"
이렇게 물어보는 사람들이 있어서
처음으로 받아보는 앱으로서의 관심이랄까
ㅜ
파이팅..!