언제쯤이면 "UI(뷰)와 비지니스(로직)를 분리해라"는 "거시기"와 동급의 의미 없는 말을 안들을 수 있을까?
뭐가 UI고 뭐가 비지니스인지 정의할 수 있나? 둘을 가르는 명확한 기준은 무엇인가? UI, 비지니스 다 추상적인 단어들이며 질문도 추상적이다. 아마 답도 추상적이겠지. 옆의 동료들에게 물어보라 UI는 뭐고 비지니스는 뭐고 이 둘을 어떤 기준으로 나눠야 되냐고. 대분분의 사람이 말하는 뷰와 로직의 정의는 동어반복을 벗어나지 못한다. 모호한 정의는 무딘 칼이다. 무딘 칼로는 깔끔하게 자를 수 없다.
UI와 비지니스를 나누면 뭐가 좋아서 나누라고 하는 걸까? 뭐가 좋을까? 뷰와 로직을 나누는 이유는 그것이 뷰와 로직이기 때문이 아니라 각기 다른 이유로 변하기 때문이다. 변하는 시점이 다르고 속도가 다르기 때문이다. 다른 이유로 변하기 때문에 서로 영향을 덜 받도록 나누는 것이다.
UI와 비지니스가 뭔지는 모르겠지만 무엇이건 간에 같이 변한다면 한 곳에서 고칠 수 있도록 같이 두는 것이 더 이득이다. UI라도 UI를 구성하는 각 부분이 다른 이유로 변한다면 서로 간섭을 덜 받도록 분리하는 것이 이득이다.
"뷰와 로직을 분리해라" 이런 의미 없는 말은 이제 그만하자.
덧글
개인적으로 테스트 용이성때문에 콘솔 입력이나 텍스트파일 읽고 쓰거나 간단한 스윙 UI를 만들어서 테스트하는데 이렇게 다양한 UI를 적용해보면 비지니스 로직과 UI로직이 구별이 잘가기는 합니다. ...만 이렇게 테스트 하는 사람은 별로 못보기는 했네요.
한가지 생각해볼 점은 어디까지 어떻게 달라질지는 어디까지나 추측이라는 점입니다. 여기까지는 변할 수 있겠지, 여기부터는 변하지 않겠지하는 가정에 따라 뷰와 로직의 경계가 정해집니다. 추측이기 때문에 이런 저런 실험을 하다보면 점점 경계가 드러나는데 이 과정에서 뷰와 로직의 경계가 자주 변하더군요. 밀리네스님도 비슷한 경험을 하셨으리라 생각합니다.
뷰와 로직의 절대적인 정의가 있어서 주어진 조건에 맞는 뷰와 로직의 경계를 연역적으로 도출해낸다기 보다는 주어진 조건에 잘 맞는 경계를 탐색하는 것이 프로그래머가 뷰와 로직의 경계를 정하는 과정과 더 비슷하다고 생각합니다. 알맞은 경계를 빨리 찾으려면 다양한 경계를 실험해야하고, 경계를 이리 저리 쉽게 바꿔 볼 수 있어야 합니다. 뷰와 로직을 명확하게 분리해야 한다는 명분 아래 경계를 바꾸기 어렵게 만들려는 흐름이 있어서 안타까운 마음에 쓴 글이었습니다.
이런 저런 기능을 넣다가 경계가 변하더라구요...
특히나 UI 로직은 테스트 하기 까다로와서
버그가 나오더라구요...
여긴 응과장님 블로그?
미투데이 때문에 자꾸 짧게 쓰게 되네요..
이런 저런 실험을 하는 이유가
실제로 기능 구현시 발생하는 것들에 대한 최대한 빠른 피드백을 구하기 위해서인데.
경험에 의해 미래에는 이런 방향으로 변경될 것이다 라는 예상에 의존할 수 밖에 없을 것 같습니다.
그래서 밀리네스형처럼 일정 패턴을 기본적인 실험을 정형화 시킬 수 있는 것겠구요..
저 같은 경우는 아직까지는 경험이 부족한건지
UI로직인 줄 알고 짰는데 상황에 따라 이것저것 다 돌려막네? 이건 비즈니스 로직으로 옮기자~
라던지...
이 시나리오는 절대 바뀌지 않습니다~ 라고 해서 만들었는데
이쪽에서도 비슷하게 보여주세요~ (하지만 다른 동작)라면서 UI로직으로 으샤으샤 옮기자 한다 든지
이런 경우를 몇번 겪고 나니
UI로직이 무슨 의미이며 비즈니스 로직이 무슨 의미인가
의문이 들고 있습니다.
디자인 패턴 공부할 때 항상 느끼던 것이었지만,
무엇이 변경되고, 무엇이 변경안되는 것인지
에 대해 항상 신경을 곧두세우는 것이
고수의 자세인 것 같습니다.