인프런 커뮤니티 질문&답변
작성한 질문수
MVC 패턴의 중복코드에 대한 질문입니다.
해결된 질문
작성
·
402
5
안녕하세요, 김영한 팀장님.
다른 학습자분께서 남겨주신 질문에 대한 답변 내용 중 '연통배관'이라는 단어를 보고 , 기존 업무에서 해오던 프로젝트가 생각나서 조언을 얻고자 질문 글을 남깁니다.
해당 프로젝트에서는 동일한 기능에 대하여 사용자 화면과 관리자 화면의 코드(MVC)가 분리되어 있는 형태를 띄고 있었습니다.
(예를 들어, 웹 사이트 Pop Up)
다만, 실제 코딩을 해보았을 때 Controller 클래스는 그렇다하더라도 Service와 Repository 그리고 Domain 클래스(또는 VO)가 파일명(클래스명)만 다를 뿐
실제 하는 일은 사용자 화면에서나 관리자 화면에서 동일한 구조를 띄고, 동일한 기능을 하고 있어서 신경이 쓰였는데요.
(도메인 클래스 멤버 구성들, Service와 Repository 기능[팝업 저장, 조회, 수정, 삭제])
현재 속한 그룹의 코딩 스타일이 원래 이렇구나 해서 습관(?)이 되어버린 것이 '연통배관'이라는 단어를 보자마자 반성을 하게되었습니다.
정리하면 좋은 코딩 습관은 사용자, 관리자 화면이 분할이 되어 있다고 하더라도, 각 화면에 사용할 MVC 패턴 구조가 아니라
최대한 중복 코드를 줄인 MVC 패턴 구조를 사용하여 사용자, 관리자 화면 모두에서 사용할 수 있는 기능을 구현하는 것이 올바른 코딩 습관이 맞는 거겠지요?
긴 글 읽어주셔서 감사합니다.
답변 2
13
안녕하세요. Henu님 좋은 질문입니다.
아~ 풀고 싶은 썰이 엄청 많네요 ㅋㅋㅋㅋㅋㅋ
제가 완전 주니어 시절에 금융권 SI 프로젝트에 참여적이 있습니다.
당시 아키텍트분이 화면 단위로 담당자를 지정하고, 협업 없이 프로젝트가 진행되었습니다. 각자 자신의 화면만 열심히 처리하면 되었던 것이지요. 공통화는 공통 팝업 정도였습니다.
프로젝트가 끝나고 확인을 해보니 완전히 동일한 회원 조회 쿼리가 11번 반복된 기억이 떠오르네요. 다른 모듈들을 말할 것도 없구요.
결국 이렇게 되면 개발을 할 때도 누군가 개발을 해 둔 부분을 가져다 쓰면 되는데, 각자 따로 개발을 하고 있으니 시간이 더 소비되지요. 그런데 진짜 문제는 변경입니다. 애플리케이션은 개발은 몇달만에 끝나지만 운영과 요구사항 변경은 수년동안 지속되니까요.
저는 애플리케이션을 잘 설계했나 못했나는 바로 변경에서 드러난다 생각합니다.
변경이 있을 때 누군가 아 그럼 이 부분만 변경하면 됩니다! 라고 명확하게 말할 수 있다면, 응집성 있고, 역할과 책임이 잘 나누어진 그러니까 잘 설계된 애플리케이션이라 볼 수 있습니다. 반면에 변경이 있을 때 개발자들이 당황하고? 변경 범위가 예측이 안되고, 두렵다면 잘 설계된 애플리케이션이라 보기 어렵습니다.
그런데 여기서 꼭 공통화 하는게 맞는가? 라고 하면 이 부분도 또 고민을 해보아야 합니다.
여기서는 2가지 고민이 필요합니다.
변경이 발생할 때 둘다 변경해야 하면 하나로 합치는게 더 나은 선택일 확율이 높습니다.
그런데 변경의 라이프사이클이 다르다면 분리하는게 더 나은 선택일 수 도 있습니다.
결론적으로는 똑같이 사용하는 기능은 공통화 하고, 변경의 라이프사이클이 다르다면 이 부분은 분리하는게 더 나은 선택일 수 있습니다.
사용자 화면과 어드민 화면은 변경의 라이프사이클이 다르기 때문에 화면 파일은 분리하는게 더 나은 선택일 확율이 높습니다. 다만 뒤에서 회원을 조회하는 기능이 똑같다면 화면은 다르지만, 회원을 조회하는 컴포넌트는 공통으로 사용하는게 더 나은 선택일 확율이 높습니다.
도움이 되셨길 바래요^^
4
정말 좋은 답변 감사드립니다!
다음 실무 프로젝트부터는 꼭
말씀해주신 '공통화'를 고려하여, 중복된 코드를 최대한 줄이는 방식으로 개발을 해야겠다는 생각이 들었습니다.
(물론 팀원들 간의 커뮤니케이션 및 협업 도구들을 활용해야겠지만요!)