프로젝트에 디자인패턴을 도입하려면 정말 힘들어요.
알림 시스템 새롭게 손보면서 각 알림 단계 별로 팩토리 메서드 패턴과 브로커 패턴을 적용해 봤습니다.
팩토리 메서드 패턴은 enum 값을 활용하여 전략패턴처럼 구현하였고, 브로커 패턴은 각 알림이 사이트 내부에서 뿐 아니라 이메일과 카카오알림톡으로도 나가야 하는 상황을 상정하여 만들었죠.
저번에 프로젝트에 디자인패턴 적용하고 팀원들이 너무 힘들어 하던게 떠올라 이번엔 아예 팀원 다 불러모아서 코드 리뷰 자리 까지 가졌습니다.
나름 뿌듯하게 비즈니스 로직에 영향을 줄 필요 없이 내가 만든 공통단 한줄만 호출하면 된다. 알림톡이나 메일로도 알림이 발송되어야 할 상황에선 파라미터로 정의된 코드값만 넘겨주면 된다. 새로운 알림 서비스 구현이 필요하면 정의된 추상클래스만 상속하여 구현 후 enum에 코드 값만 등록해 주면 된다. 모두 설명했는데.
문제는 그 코드를 구현하는데 왜? 그 뭐시기 패턴이라는 이해도 힘든 복잡한걸 적용해야 하는지. 그냥 하나의 클래스에 각 알림마다 메서드를 만들어서 그거 호출하면 아무나 보기 편한데, 왜 굳이 각 알림마다 클래스를 찢어서 구현해야 하는거냐? 로 1시간을 티키타카 하다가.
결국 패배하고, 다 밀어버린 다음 하나의 클래스에 메서드를 나눠 각 코드별로 if문 떡칠해서 몽땅 쑤셔박았습니다.... 그제서야 다들 만족하네요. 본인들은 손가락이 끊어지도록 스크롤 할지언정 한눈에 보이는 코드가 가장 좋다고 합니다.
이해는 갑니다. 되도 않고 이해하기도 힘든 이상한 패턴보다 제가 회사를 떠나도 다음에 들어올 누군가가 뭐 이따구로 더럽게 코드를 짜놨냐 화를낼지언정. 어쨋든 각 알림들이 정의된 메서드가 if분기로 나간다는 사실은 이제 막 코드 걸음마땐 초보자도 알 수 있을테니까요.
뭣보다도 제가 적용한 설계 자체가 지금 하는 작업과 맞지 않을 가능성도 존재하고, 나중에 어떤 추가 기능으로 고도화가 들어갈지 모르는 상황에서 패턴이란걸로 팔 다리 묶어두면 수정 자체도 쉽지 않겠죠.
그래도 뭔가 객체지향언어를 쓰면서 거기에 맞는 설계를 적용해 보고 싶은 욕심은 버리기가 참 힘듭니다 ㅠㅜ
오늘이 두번째 패배지만, 언젠가는 회사 서비스에 제가 설계한 무언가를 꼭 집어 넣고 말겁니다. 아직은 짬빠가 낮아서 힘든데, 대리급이 되면 진짜 싹다 제 맘대로 갈아 엎어버릴거에요.
