[Closed]아아 갖고 싶다 60 program design patterns

음.. 뭐랄까.. 디자인 패턴과 같은 방법론 책들을 보시면 여태 여러 사람들이 삽질을 해보니
이때는 이렇게 하는게 낫더라.. 라고 정리가 되어있습니다.

그런데 사실 저도 프로그램 만들면서 디자인패턴은 모르고 살았는데 나중에 디자인 패턴 책을보니
제가 그간 문제를 해결하는데 사용했던 방법이 그대로 다 들어있더군요.

즉.. 굳이 패턴을 억지로 배우고 그걸 끼워맞추실 필요는 전혀 없습니다.
프로그램 짜다보면 하기 싫어도 그 패턴들을 자동적으로 따라가는 자신의 모습을 보실겁니다.

프로그램을 짜기 위한 디자인과 설계는 매우 중요합니다.
그렇지만 프로그램을 잘 짜고 설계를 잘 하기 위해서는 지식 뿐만 아니랄 많은 경험도 필요합니다.
이론으로 탁상공론해봤자 나중에 짜보시면 아시겠지만 그다지 교과서대로 되는건 많이 않음을 아실겁니다.

---
=_= 그냥 맹목적으로 프로그램을 끄적 끄적 만들면 조그마한 프로그램도 나중에 시간이 지나면

"헉 이게 뭐지?"

이렇게 되더라구요 ㅋㅋ 웃지 마시구요. ㅠ 초보니까 그러려니 해주세요.
---

이건 사실 초보 뿐만 아니라 숙련된 조교도 마찬가지입니다.
그래서 문서화가 필요한것이죠.

제가 보기로는 60개의 패턴중 많아야 10개가 쓰일까 합니다.
(매우 주관적이므로 틀릴수도 있습니다. 저도 엄청나게 오랫동안 프로그램을 짠건 아니기에..)

초보자가 보기에 편한 책은 찾기 힘드실지도 모릅니다.
디자인 패턴도 소프트웨어공학의 일종이고, 소프트웨어공학은 대학전공 커리큘럼에 포함이 되어있으니..
어느정도 소프트웨어에 대한 기반 지식과 경험이 없으면 이게 뭔소리인가 하실겁니다. 실제 어디에 적용하면 좋은지도 모르실거구요.

그래도 보시겠다면 그리고 경제적 여건이 되신다면 비싸더라도 책은 꼭 사시고..
읽으시고나서 나중에 프로그램을 짜실때는 패턴이 목적이 아닌 프로그램을 짜는데 패턴이 도구가 되도록
염두하셔야합니다.

너무 패턴과같은 방법론에만 얽매이게 되면 나중에 프로그램을 만들기위한 방법론인지 방법론을 따르기 위한 끼워맞추기 프로그래밍인지
구분이 안가게 됩니다.

-------------------------------------------------------------------------------
It's better to appear stupid and ask question than to be silent and remain stupid.