디자인 패턴을 적용하기보다, 진짜 문제가 발생했을 때 이를 해결하기 위한 디자인 패턴을 사용하자.
이전부터 뭔가를 작업을 받았을 때 무슨 디자인 패턴을 쓰는 게 맞을까?라는 고민을 하고 여러 가지 선택지를 갖고서 질문을 해도 대부분 뚜렷한 정답을 못 받을 때가 많았던 거 같은데, 아무래도 디자인패턴을 적용하는 것은 꽤나 복잡해지기도 하고, 사전지식이 필요하다는 것이 크게 다가오는 거 같아. 이런 상황에서 디자인 패턴을 적용하기보다, 진짜 문제가 발생했을 때 이를 해결하기 위한 디자인 패턴을 사용하자. 이 말이 좀 와닿는 거 같아. 내가 디자인 패턴을 사용하려고 했던 이유는 아래와 같아.
이 코드도 언젠가는 레거시다. 빠르면 반년도 안 돼서 누군가 이 코드를 리팩터링 하고 고도화를 한다.
우리가 주로 사용하는 디자인 패턴으로 한다면 누구나 이해하기 쉽고, 편리하게 리팩토링이 가능할 것 같다.
위 2가지 생각을 갖고서 구현을 했었는데, 잘못 작성한 것들도 있고 오히려 구현보다 어떤 패턴을 사용할지 고민을 더 오래 한 거 같아. 그만큼 구현이 간단한 것이었는데 고민을 했다는 것이지.
이런 상황에서 책에서 나온 것처럼 KISS 원칙을 따랐더라면 어땠을까 싶은 생각이 지금은 드네
keep it simple principle
유지 보수성
최근에는 Compose + MVI를 구현하고 연습하고 있는데 다시 View 단 코드에서 View를 붙이는 작업이 들어왔는데, 이 코드가 MVVM + MVC가 겹쳐져 있던 상황이었어. 그런 상황에서 난 현재 View가 어떤 상태(State)인지 알고 싶은데 이 코드가 어딨는지 찾기가 되게 힘들고 디버깅도 안돼서 거의 하루 가까이 날렸던 경험이 있는데, 이런 상황에서 2가지 생각 정도가 들더라
2가지 정도? 가 가장 기억에 남네
디자인 패턴을 적용하기보다, 진짜 문제가 발생했을 때 이를 해결하기 위한 디자인 패턴을 사용하자.
이전부터 뭔가를 작업을 받았을 때 무슨
디자인 패턴을 쓰는 게 맞을까?라는 고민을 하고 여러 가지 선택지를 갖고서 질문을 해도 대부분 뚜렷한 정답을 못 받을 때가 많았던 거 같은데, 아무래도 디자인패턴을 적용하는 것은 꽤나 복잡해지기도 하고, 사전지식이 필요하다는 것이 크게 다가오는 거 같아. 이런 상황에서 디자인 패턴을 적용하기보다, 진짜 문제가 발생했을 때 이를 해결하기 위한 디자인 패턴을 사용하자. 이 말이 좀 와닿는 거 같아. 내가 디자인 패턴을 사용하려고 했던 이유는 아래와 같아.위 2가지 생각을 갖고서 구현을 했었는데, 잘못 작성한 것들도 있고 오히려 구현보다 어떤 패턴을 사용할지 고민을 더 오래 한 거 같아. 그만큼 구현이 간단한 것이었는데 고민을 했다는 것이지.
이런 상황에서 책에서 나온 것처럼
KISS원칙을 따랐더라면 어땠을까 싶은 생각이 지금은 드네유지 보수성
최근에는 Compose + MVI를 구현하고 연습하고 있는데 다시 View 단 코드에서 View를 붙이는 작업이 들어왔는데, 이 코드가 MVVM + MVC가 겹쳐져 있던 상황이었어. 그런 상황에서 난 현재 View가 어떤 상태(State)인지 알고 싶은데 이 코드가 어딨는지 찾기가 되게 힘들고 디버깅도 안돼서 거의 하루 가까이 날렸던 경험이 있는데, 이런 상황에서 2가지 생각 정도가 들더라