선생님, 개발을 잘하고 싶어요.

원시적 화폐 (돈) 야프섬의 라이 라이는 석회암을 깍아 만든 큰 원반 (그냥 돌이다) 단순한 돌이지만 수백년 혹은 수천년 정상적으로 화폐 기능을 했다. 당시에는 라이의 공급을 늘리는게 힘들었다. 즉 유량이 쉽게 높아지기 어려운 상태였다. 미국인 선장 오키프가 외국 기술력을 이용해서 라이를 쉽게 채취하면서 상황이 달라졌다. 유량이 너무 쉽게 높아지며 라이는 화폐기능을 상실했다. 화폐 기능을 잃은 돈은 결국 저량/유량 비율 하락 때문이다. 유량이 늘거나, 저량이 줄거나 저량이 주는 것은 화폐로 사용할 재화가 시간이 지나며 희석되는 것을 생각할 수 있겠네 (사과는 상한다, 차는 감가한다.) 유량은 다양한 요인으로 폭발적으로 늘 수 있겠다. 법정화폐 기준으로는 그냥 찍어내는 것도 가능 (초인플레) 만들기 쉬운 ..

화폐(돈)에 대한 챕터 생존을 위해서 가치를 교환하고 싶음 나는 사과를 가지고 있는데 상대방은 고기가 있음 가치를 직접교환하는 물물교환 경재가 커지며 전문화된 가치를 만들게 되고 낯선 사람과 가치를 교환해야하는 일이 생김 욕망불일치가 커지게 된다. 규모 불일치 (집을 사고 싶은데 신발로 교환 가능? 집의 일부만 똑 띠어서 교환 가능?) 시점 불일치 (상하기 쉬운 물건(사과) vs 오래가는 물건(차)) 장소 불일치 (집을 똑 때어서 가져올 수 있음?) 간접교환의 필요성 대두 화폐(돈)의 본질적 기능 → 교환매개 다른 물건과 바꾸는 재화, 그 이상도 그 이하도 아니다. 화폐도 결국 재화에 지나지 않는다. 투자와는 다르다. 투자는 수익을 만듬 돈은 위험이 낮음 (그렇게 생각함) 돈이 유동성이 제일 높음 그러면..

한빛미디어 활동을 위해 책을 제공받아 작성된 서평입니다. 저는 요즘에 돈을 어떻게 벌 수 있을지 고민이 정말 많습니다. 개발자로써 프로그래밍 공부를 잘 해서 고소득 직업을 잡는 것도 그런 일환에서 이루어집니다. 그런데 코로나 이전 금융에 일자 무식이던 저는 코로나 이후 소위 말하는 "벼락거지"가 된 느낌을 받았습니다. 주변에선 부동산, 주식, 코인을 통해서 수 억을 벌었다는 이야기가 들려왔습니다. 조급한 마음에 친구 따라서 들어간 주식에서 -50%의 실패를 맛보기도 하였습니다. 하지만 그런 실패를 한 이후 억울해졌습니다. 그래서 더 공부하고 공부하며 재태크 실력을 쌓아가고 있습니다. 제가 중점적으로 공부하는 분야는 미국 주식입니다. 다양한 미국 주식 자료를 찾아보고 있습니다. 유튜브에서는 JCTV, 소수..

이론은 여기까지, 이제는 실전 경험을 하며 배워야 하는 단계입니다. 하지만 이것도 밑바닥부터 하면 효율적이지 않겠죠. 실전 경험을 하면서도 더 선배 개발자들이 이미 실무에서 반복적으로 고민하고 사용하고 효과를 본 툴들을 배우며 고민할 때가 된 것 같습니다. 그 시작 점은 디자인 패턴과 프레임워크인데요. 디자인 패턴은 바로 다음 부터 공부를 진행해 가면 좋을 것 같습니다. 프레임워크의 핵심 개념이 의존성 역전이라는 내용은 지금까지 제가 생각하던 안드로이드 프레임워크에 대한 개념을 명문화 한 느낌을 받았습니다. 안드로이드 컴포넌트에 한해서 내가 할 수 있는 것은 프레임워크를 공부하고 프레임워크가 특정 시점에 호출할 거라고 약속한 함수들을 구현하고 위치 시키는 것 뿐이였는데 이를 “제어 권한이 프레임워크로 역..

지금까지 읽은 오브젝트의 모든 내용을 총 망라한 챕터입니다. 전화요금 설계를 일관성 있는 협력으로 구성하며 지금까지 설명한 모든 개념을 총 동원하고 리마인드 시킵니다. 역할, 책임, 협력에서 시작해서 의존성 역전 법칙, 개방 폐쇠 원칙, 리스코프 치환 원칙을 모두 활용하고 상기시킵니다. 도입일관성 있는 협력 패턴을 적용하면 코드가 이해하기 쉽고 직관적이며 유연해질 것이다. 객체지향의 목표는 적절한 책임을 수행하는 객체들의 협력을 기반으로 결합도가 낮고 재사용 가능한 코드 구조를 창조하는 것이다. 설계에 일관성 부여하기 객체 지향에서 기능을 구현해야 한다? 기능을 위해 필요한 책임을 식별한다. 책임을 할당할 적절한 객체를 선택한다. 다양한 설계 경험을 익혀라. 디자인 패턴을 학습하고 변경이라는 문맥 안에서..

단순히 코드 재사용을 위한 상속에 서브클래싱이라는 이름을 붙히고 타입 계층을 만들기 위해서 사용하는 상속에 서브타이핑이라는 이름이 있다는 사실을 알게된 챕터입니다. 이런 구분을 알게 되니까 LSP의 진정한 의미에 대해서 조금은 알게된 것 같습니다. 원래는 “당연히 부모 타입에 자식 타입 인스턴스를 넣고 사용할 수 있는데 뭔 소리야?”라고 생각하고 대수롭지 않게 여긴 설계 원칙이였는데요. 이번 챕터를 통해서 객체 지향 설계의 정수가 아닌가? 라는 생각이 들게 되었습니다. 우선 LSP와 다형성의 관계가 매우 재밌었습니다. 객체 지향을 처음 배울 때 부터 우리는 다형성에 대해서 배웠습니다만 다형성을 단순히 Overloading 정도로 생각하고 있었던 것 같아요. 타입이라는 개념으로 역할을 정의하고, 코드를 O..

다형성을 달성하게 만든 동적 바인딩에 대해서 탈탈 턴 챕터입니다. 클라이언트가 보낸 메시지가 실제로 런타임에 어떻게 구체 클래스의 메서드를 실행하게 되는지 상속의 관점에서 잘 설명돼있습니다. 여기서 더 나아가서 상속은 이러한 동적 바인딩을 위한 경로 정의에 방법일 뿐이라는 이야기와 함께 경로 정의를 컴파일 타임 상속으로 처리한 게 아니라 런타임 객체간 체이닝으로 처리한 자바스크립트의 prototype의 예시를 들어주는 데 엄청 신기했습니다. 그런 식으로 실제 실행 시점 메서드를 결정한다는 메커니즘에서 합성이 어떻게 상속의 대체가 되는지 설명하는 부분까지 완벽했다고 생각합니다. 도입 상속 이외에도 다형성을 구현할 수 있는 방법은 많다. 다형성은 런타임에 메시지를 처리하기에 적합한 메서드를 동적으로 탐색하는..

상속의 문제점을 지적하며 합성의 장점을 설명하는 챕터입니다. 조합의 폭발적인 증가는 실제로 경험해 본 적이 없지만 부주의하게 상속을 사용하는 경우 당연히 발생할 것 같습니다. (실제로 경험 안해보는 게 정신 건강에 좋을 것 같네요.) 합성을 사용하는 게 컴파일타임 의존성과 런타임 의존성을 다르게 설정할 수 있는 방법이라는 걸 알게되었습니다. 지금까지 저자가 강조했던 것 처럼 유연한 설계를 위해서는 이 둘의 차이가 있어야 한다고 했던 지점과 일치하는 듯 하네요. 하지만 결국 합성만이 만능키라는 게 아니고 상속이 가지고 있는 문제 (컴파일타임에 의존성을 런타임에 못 바꿈)을 해결할 수 있다면 mixin과 같은 방법도 좋아보입니다. 상속, 합성, 믹스인 모두 도구일 뿐이라는 점을 상기시키는 것 같습니다. 도입..