휼륭한 개발자들은 디자인 패턴에 집착하지 않는다.
“나는 MVVM이 좋은 것 같아”, “VIPER 패턴이 짱이지”, “MVC가 최고야!”
“adapter 패턴이 우린 꼭 써야해!”, ... etc
컨퍼런스를 듣거나 혹은 동료들끼리 이야기하다보면 이런 이야기를 하곤 합니다.
사실 점심 뭐먹을지 이야기함
현재 iOS 개발자들 사이에서 패턴들이 핫한 이슈죠. 그리고 각각 많은 의견이 있습니다. 어떤 분들은 신념에 가까운 분도 계시구요.
각각의 패턴들은 다양한 문제들을 해결하기 위해서 일반화된 형태로 구성하고 있죠.
(그래야 최대한 다양한 케이스에 대응이 가능하니까요)
이 글에서는 그럼에도 불구하고, 훌륭한 Swift 개발자가 되기위해선 많은 패턴은 필요하지 않다고 말합니다.
(이 글에서 패턴 자체를 몰라도 된다는 뜻이 아니라 훌륭한 개발자의 충분조건이 아니라는 말을 하고 싶은 것 같습니다.)
모든 패턴은 “원리”에서 시작되었다.
그러므로 “원리” 를 배우는 것에 집중하면 된다.
- Modularity (모듈화)
- Reusability (재사용성)
- Easy to read (가독성)
- Easy to modify (변형 가능성)
위 4 가지 원리는 우리가 코드를 작성할 때, 항상 고려해야하는 원칙이자 원리입니다. 이 원칙들은 또 다른 원칙을 만들어 내고 그 규칙을 따르게 되겠죠.
하지만, 근본적인 원칙은 위 4 가지입니다
그리고 나머지는 위 4 가지를 지키기 위한 다른 원칙이 생겨난 것 뿐입니다.
(나머지 원칙들은 변할 수도 있겠죠. 그럼에도 위 4 가지는 변하지 않습니다.)
사례로 이야기해보면
프로젝트를 수행할 때, 어떤 일이 벌이질지 모릅니다. 만약 지금 만든 어플리케이션의 규모가 점점 커지고 다양한 기능들이 추가된다고 생각해보세요. 그러면 어떤 디자인 패턴을 사용해야할지 감이 잡히시나요?
글쓴이는 말합니다.
만약 위 4가지 원칙을 이해한다면, 너는 시작부터 4 가지 원칙을 적용할 수 있다.
- 모듈성을 유지하는지 확인한다.
- 기회가 있을 때, 재사용할 수 있는 것들을 재사용할 수 있도록 구성한다.
- 코드를 문서화 한다.
지금 위해서 말한 3 가지는 지금 당장 적용할 수 있고 해야하는 것들입니다. 어떤 상황이나 특정 상황에서만 적용되는 룰이 아니죠.
만약 지금 어떤 패턴을 공부할지 걱정이 많이 된다면, 고민해야할 것은
지금 내가 4 가지 원칙을 잘 지키고 있는가?
만 고민하면 됩니다.
- 글쓴이의 실제 사례
글쓴이는 뱅킹앱을 인수받아서 일했다고 합니다.
그 앱은 하나의 큰 코디네이터를 구성해서 모든 컨트롤러에 접근하고 있었습니다.
그들은 코디네이터 패턴을 사용하는 목적을 잃어버린 것이죠.
이러한 예시가 패턴보다 원칙이 더 중요함을 보여줍니다.읽기 좋은 코드가 좋은 코드다.
어떤 바보라도 컴퓨터가 이해할 수 있는 코드는 작성할 수 있습니다.
좋은 프로그래머는 “인간이 이해할 수 있는 코드”를 작성하는 사람입니다.
- 마틴 파울러 -
코드는 읽기 쉬워야 합니다. 이유를 설명드리죠.
- 다른 개발자들을 위해서
- 미래의 자신을 위해서
공감하지 못하신다면, 아직 코딩 공부를 얼마 안하셨을 수도 있습니다.
(혹은 천재)
공리주의관점에서 보더라도 코드는 읽기 좋게 작성해야합니다.
왜냐하면 모두에게 이익이 되거든요.
어떤 패턴을 사용하는지는 중요하지 않습니다. 하지만 코드를 읽기 어려운 것은 추후에 다시 손봐야할 “기술 부채” 로 쌓이게 될 겁니다. 왜냐하면, 다른사람이 읽는데 시간을 걸리게 할 것이고(-1) 내가 그 코드를 다시보는데 시간이 걸리고(-1) 나중에 추가 시간을 들여서 고쳐야합니다.(-1)
글쓴이가 재미있는 예시를 듭니다.
다른 사람이 의미없는 재귀함수를 작성했다고 해서, 바보라고하고 자기자신은 이걸 알아보는 멋진 사람이라고 착각하지 마십쇼. 읽기 쉬운 재귀함수라면 오히려 도움이 됩니다.
-> 코딩테스트를 공부하다보면 재귀함수의 단점과 시간복잡도를 계산하면서 이 문제처럼 생각할 수도 있겠다라는 생각을 했습니다.
좋은 개발자의 지표는 “다른 사람이 얼마나 코드를 쉽게 변경할 수 있도록 구성했는지” 입니다.
- 글쓴이의 사례
글쓴이는 프로그래밍 한 이후에 "플러프(fluff)" 라는 것을 작성했다고 합니다.
그 당시 코드를 보거나 작성하면서 이해하기 어려운 것에 대해서 어떤 표시를 해두었고,
그것이 "훌륭하다!" 라고 생각했다고 합니다.
지금와서 보면 이 행동은 말도안되는 행동이였다는걸 느낀다고 이야기 합니다.-> 지금의 제가 그런 것 같습니다. 제가 당장 이해하지 못하는 코드를 나타내면, 그것은 무언가 대단한 기술이 있고 앞으로 공부해야할 분야라고만 생각합니다. 그렇게 생각하는 것 자체는 공부의 동기는 되겠지만, 기준이 없는 공부가 될 것이고 이게 왜 필요한지 언제 필요한지 어떻게 써야하는지에 대한 답은 못찾을 것 같네요. 저도 반성합니다.
원칙 주의자는 유연성이 떨어질 수 밖에 없다.
(여기서의 원칙은 패턴을 지키기 위한 원칙을 의미합니다.)
글쓴이는 말합니다.
평생 동안 하나의 패턴이 프로젝트의 요구사항에 딱 맞는 경우는 단 한번도 본적이 없습니다.
이 말은, 특정 패턴의 규칙이 정확히 들어맞는 경우는 없고 자신의 상황에 맞게 변형하고 적용해야한다고 생각합니다.
패턴에 집착하면, 현재 상황은 고려하지 않고 패턴에 끼워 맞추겠죠. 그러면 패턴을 사용한 목적을 잃어버리는 겁니다. 패턴은 “프로젝트의 문제 해결” 을 위해 사용했는데, 문제를 야기하는 결과를 초래한 것이죠.
패턴이 존재하는 이유를 진정으로 이해한다면 애플리케이션의 진화(변화 혹은 구체적인 조건)에 맞게 조정할 수 있습니다. 그것이 모든 개발자의 목표가 되어야 합니다.
결론
이 글을 읽고 “디자인 패턴은 무용하다.” 라고 이해하지 않았으면 한다고 합니다.
(다만, “뭣이 중한디” 에 대한 물음을 놓지 말라고 당부하는 글 같습니다.)
패턴을 공부할 때는, 패턴이 존재하는 이유를 생각하고 어떤 원칙을 지키기 위해 구성된 것인지 고민한다면 큰 도움이 된다고 합니다.
계속해서 패턴은 나올 것이고 지금의 패턴은 또 사라지기도 합니다. Swift 에 국한된 이야기는 아니죠.
그래서 패턴을 암기하는 것보다 디자인의 원칙 (위에서 말한 4 가지 원칙)에 집중한다면,
흐름이 변해도 중심을 잡고 훌륭한 Swift 개발자가 될 수 있다고 말합니다.
감상
사실 최근에 저는 디자인 패턴 공부에 심취해 있습니다.
아직 특정 패턴에 신봉할만큼 믿음이 있진 않습니다만, 패턴을 공부하다보면 특정 문제가 발생했을 때, 어떻게 해결할지 고민할 시간을 줄여주더라구요. 그리고 나중에 코드를 보더라도 기억하기 쉽다고 해야할까요?
규칙이 없는 텍스트에 규칙을 부여하는 게 저는 디자인 패턴이고,
문제를 해결하기 위해 쌓아놓은 논리들이 디자인 패턴이라고 생각합니다.
(제가 썸네일 사진을 도구 사진을 올려두었죠. 그 이유가 저는 디자인 패턴은 "도구" 라고 생각하기 때문입니다.)
이런 마음을 가지고 공부하니까, 디자인 패턴 공부가 지루한게 아니라 정말 재미있고, 모르는게 나오면 오히려 기대가 됩니다. 빨리 배워서 제것으로 만들고 싶더라구요.(좋은 무기(혹은 도구?) 를 가지게 된다는 느낌이랄 까요.)
혹시 디자인 패턴에 대해서 스트레스 받으시면서 공부하신다면,
디자인 패턴 공부는 내려놓으시고 원리를 하나씩 적용해보시면,
이너피스를 챙겨보세요..ㅎ
복습
- 원리를 잊지 말아라.
- Modularity (모듈화)
- Reusability (재사용성)
- Easy to read (가독성)
- Easy to modify (변형 가능성)
-
코드는 반드시 읽기 쉬워야 한다.
-
원칙 주의자가 되지 말자. (디자인 패턴에 있어서)
-
프로젝트의 패턴을 적용한 이유를 잊지 말자.
원본 글 링크
