서론
처음 이 책을 공부해야겠다는 생각을 가지게 된 이유는 다음과 같다.
1.
난 코드를 너무 더럽게 만든다.
2.
내 코드를 보는 사람들이 쉽게 이해할 수 있는 코드를 만들면 좋겠다.
3.
API를 볼 때 이해를 못하고 사용하는 경우가 많았다. 플로우를 이해하고 싶었다.
본론
어렵다. 필자는 3번 정도 읽었다.
사실 이렇게 읽고도 “너 이거 해봐”하면 잘 못한다. 이유는 다음과 같다.
1.
디자인 패턴을 적용 시킬만한 문제를 직면한 적이 없다.
2.
그만큼 많은 사람들과 같이 코드를 작성할 일이 없다.
3.
이것을 적용할 만한 서비스를 만들어 본 적이 없다.
모두 공감할 것이다. 그래서 최대한 이 책을 정리할 때 다음과 같은 생각을 가지고 정리해보려고 했다.
1.
코드로 표현하지 말아보자
2.
큰 그림을 보자. 뭐가 불편해서 등장했고, 뭘 위해서 이걸 사용해야 하는지 생각하면서 읽자.
왜 이렇게 생각을 하고 정리하려고 했냐면 너무 코드 관점으로 생각을 하고 이해하려고 하니 잘 이해를 하지 못했기 때문이다. 그러다가 문득 그런 생각이 들었다. 3회차에 읽을 때 이다.
“왜 디자인 패턴이 만들어 진 것일까?”
근데 책의 끝에도 그런 말이 적혀 있던 것이 생각났다. 문제가 반복되고 이를 해결하기 위한 해결책으로 등장했다는 것이다. 즉, 문제가 있고 이를 해결하기 위한 것이다. 너무 당연한 것을 잊고 있었다.
1.
첫 번째 정독
와 이런게 있네?? 이걸 하면 이렇게 되는거야?
2.
두 번째 정독
아 맞다. 이런게 있었지. 근데 생각보다 더 복잡해지던데?
이 당시의 생각은 아직 반복되는 문제에 대한 개념이 없었다.
3.
세 번째 정독
모든 패턴은 반복되는 문제를 해결하기 위해서구나. 이런 비슷한 개념들이 모든 컴퓨터 과학에 적용되어 있구나.
현재 시점에서는 CS공부도 하고 있었을 적이라서 모든 문제가 결국 천재들이 만든 컴퓨터 기술에서 시작되었다는 것을 어느 정도 깨달았다. CS의 중요성.
또한 이 과정에서 소소한 깨달음을 얻을 수 있었다.
1.
자신의 시점과 서비스의 상황에서 디자인 패턴을 적용하지 않고 만들어낸 코드가 최선에 선택이라면 디자인 패턴을 적용하는 것 보다 좋을 수 있다는 것이다.
2.
디자인 패턴이라는 코드 관점이 아니라 전체적인 플로우가 유사한 컴퓨터 개념이 무진장 많구나.
이건 유튜브의 os강의를 보다가 메시지 큐를 이용하는 것을 보았다. 근데 강의를 해주시던 분이 “이렇게 하면 타 서비스에서 메시지 큐만 바라보게 되죠?” 라는 말을 했다. 이때 무릎이 부서져라 쳤다. 왜냐하면 이게 의존성을 끊는 방식과 매우 흡사했기 때문이다.
결론
결국 디자인 패턴도 특정한 문제가 반복적으로 발생할 때 해결할 수 있는 선택지 중에 하나다. 꼭 그 문제를 디자인 패턴으로만 해결하려고 할 필요 없다. 하지만 디자인 패턴을 어느 정도 이해하면 모든 컴퓨터 과학에서 문제를 해결할 때 적용했던 개념, 기술 등과 유사한 것들을 쉽게 이해할 수 있게 될 것 같다. 나는 이제 CS공부하러 가야겠다.