객체지향의 사실과 오해 (2022.03.09.)

이상한 나라의 앨리스는 매력적이야

포지션이 애매했다.

객체지향을 처음 배운 사람은 확실히 아녔고...

이후로 이어지는 ‘오브젝트’라는 책의 프리퀄.

객체지향프로그래밍과 소프트웨어공학이 녹여진, 자연스럽게 녹아있다.

만약 읽는다면 소프트웨어공학 수업을 듣고 나서 읽으면 좋을 듯

그래도 객체지향프로그래밍 신경 쓰지 않고 개발했었는데

신경 쓰게 됨.

기존 코드, 특히 이번에 게임 프로젝트 하나 하고 있는데

뜯어고칠  진짜 엄청 많겠다

망함 오늘 고치려나

근데 이 책을 세줄 요약도 가능할 듯

객체지향의 사실과 오해

오해 : 객체지향은 현실을 반영하는 것

사실 : 객체지향은 현실을 은유하는 것

 

나머지는 저 요약에 대한 설명과 구현 방법이다.

---

(2022.06.27.)

윗글에서 하고 있다는 '이번에 게임 프로젝트 하나'

아직 완성 못했다.

레바 작가의 '던전 속 사정'이라는 웹툰 완결 기념 팬 게임 만들던 건데

아직도 완성 못했다.

그리고,

그 웹툰도 아직 완결 안 났다.

---

지금 이 책을 팀 동료(=신행이)한테 추천하면서 빌려줬었는데 내가 처음 읽을 때는 저런 생각이었구나...

책을 읽고 난 후 감상에 따라서 이모티콘 평가를 매기고 있는데

그다지 높은 점수를 받은 책은 아니더라.

 

그런데 나중에 돼서, '역할-책임-협력, 그리고 메세지'라는 표현이 필요해진 것을 보면 그렇게 짜게 줄 책은 아녔던지도...?

---

요즈음, 계속 게임 개발하고 있다.

종종 협업도 한다.

하지만 개발 속 협업은 어떻게 해야 할지 감이 올 듯 말 듯 하다.

큰 프로그램은 여러 애플리케이션으로 이뤄지기 때문에, 애플리케이션 단위로 나누는 것은 확실해 보인다.

그러고 이제 애플리케이션끼리 주고, 받을 메세지(=인터페이스)만 정하는 거지.

그런데 하나의 애플리케이션을 개발한다면? 또는 규모가 작아서 프로그램 자체가 작다면?

처음에는, 아 그래도 협업하는게 더 빠르지~ 란 생각이었는데,

일정 규모 이하라면 그냥 혼자 하는 게 더 빠를 수도 있겠더라.

 

실제 현업에선 그것을 어떤 기준으로 정할까.

이상하게 다른 부서, 예를 들면 기획이나 디자인 부서와 개발 부서가 협업하는 방법에 대한 글들은 많은데,

정작 개발 부서 내에서의 협업에 대해 적은 글은 많지 않다.

그냥 객체지향을 따르고, 소프트웨어공학을 따르란 걸까.

 

최근에 알게 된 프로그래밍 방법의 하나가, Pair Programming, 즉 짝 프로그래밍이라는 건데

하나의 프로그램을 5분씩 번갈아 가면서 코딩을 하는 거다.

오우 쉡... 5분 동안 고민하다 토스해도 되는거야?

아마 이런 생각 하는 프로그래머 거르는 용도일 수도 있겠다. ㅎㅎ

한 편으론 그만큼 무적권 협업해야함을 강조하는, 대표적인 사례일지도 모르겠다.