Books

Home /
Categories /
Books

데이터 중심 애플리케이션 설계

Books
2022년 4월 27일

이 책은 총 3부로 구성되어 1부에서는 근본 개념에 대해 설명하고 2부에서는 데이터를 분산 저장하기 위한 내용을, 3부에서는 한 데이터셋에서 다른 데이터셋을 파생하는 시스템애 대해 설명한다. 1장. 데이터 시스템의 기초 1) 신뢰성 잘못될 수 있는 일을 결함이라 부른다. 이 결함을 예측하고 대처할 수 있는 시스템을 내 결함성/탄력성을 가졌다고 말할 수 있다. 결함과 장애는 동일하지 않은데, 결함은 사양에서 벗어난 시스템의 한 구성 요소로 정의되지만, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우이다....

Go in Action

Books
2022년 3월 29일

저는 개인적으로 GoLang을 접한지는 꽤 되었습니다. 제가 Go를 학습할때는 인터넷을 통해 충분히 학습할 수 있었는 데, 키워드들이 많지 않았고 http://golang.site 에 대부분 필요한 내용은 설명되어있어 무리없이 학습할 수 있었습니다. 그런데 책을 구매하게 된 이유는 요즘 읽을 책이 마땅치 않았기도 하고, Go 책을 개인적으로 소장하고 싶어 구매해본 책입니다. 책이 나온지는 꽤 된 책입니다. 하지만, go언어가 version이 높아지면서 언어에 큰 변화가 생기지 않았기 때문에 별 무리 없이 책을 읽을 수 있었습니다....

디지털 트랜스포메이션 엔진(ACCELERATE)

Books
2022년 3월 23일

제목부터 낯선 이 디지털 트랜스포메이션 엔진이라는 책은 Redit을 통해 처음 접하게 되었고, 책의 원제목은 ACCELERATE:The Science Of Lean Software and DevOps:Building and Scaling High Performing Techonology Oragnizations 이다. 이름만 들었을때는 책 내용이 굉장히 어려워 보인다. 하지만, 쪽수도 얼마 안되고 내용이 재미있어 굉장이 빨리 읽힌 책이었다. 책의 전체적인 내용은 설문조사와 연구를 통해 DevOps가 소프트웨어의 전달 성과, 팀원들의 만족도, 더 나아가 고객만족도에 미치는 영향을 분석하고 고성과 조직으로 가는 요소를 제시하는 책이다....

가상면접 사례로 배우는 대규모 설계 기초

Books
2022년 3월 23일

나는 얇은 책이거나 꼭 소장할 책이 아니라면 주로 알라딘 에서 ebook으로 책을 구매해서 읽는다.(전공 서적은 주로 너무 두꺼워 집에 둘 곳이 없다…) 책을 구매한 날도 알라딘에 어떤 ebook이 등록되었나 보고 있었고, 이 책의 제목이 굉장히 흥미를 끌었고 바로 구매를 해버렸다. 처음 구매후, 11장 까지는 굉장히 재미있게 읽어가다가 점점 루즈해져갔고, 읽는것을 한동안 중단했었다. 업무가 바쁘기도 했고 다른 DDD책이 더 재미가 있었다.. 그러다가 최근 부터 이직준비를 조금씩 하고 있었는데, 이 때문인지 책을 다시 읽기 시작했고 11장 부터 끝까지 한번에 다 본 것 같다....

도메인 주도 설계로 시작하는 마이크로 서비스 개발

Books
2021년 12월 27일

1. 마이크로서비스를 위한 조건 1) 업무 기능 중심의 팀 기술별로 팀이 나눠지게 되면 서비스 한개를 개발하는데 많은 의사소통이 필요하고 의사결정이 느려진다. 업무기능을 중심으로 다양한 기술을 가진 사람들이 하나의 팀이 되어 서비스를 만들어야 한다. 2) 폴리글랏 프로그래밍 각각의 서비스에 맞는 효율적인 방법론과 도구, 기술을 찾아 적용. 3) 개발 생명주기는 프로젝트단위가 아닌 제품 중심 초기에 모든 일정을 계획하고 요구사항 정의, 설계, 개발을 진행하는 것은 변경이나 새로운 아이디어를 포용하기 힘들다. 제품중심의 애자일 개방 방식을 채용하여 단기간의 스프린트로 계속한 개발/피드백으로 제품을 지속적으로 변화, 개선하는 것이 마이크로서비스이다....

오브젝트: 코드로 이해하는 객체지향 설계

Books
2021년 11월 12일

1. 객체지향 설계 설계란 코드를 배치하는 것이다. 좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계 요구사항은 항상 변하기 마련이다. 2. 객체지향 프로그래밍 부모 클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴을 TEMPLATE METHOD 패턴 이라고 한다. 자식 클래스가 부모 클래스를 대신 하는 것이 업캐스팅 다형성이란 동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답할 수 있는 능력 상속은 구현 상속이 아니라 인터페이스 상속을 위해 사용해야 한다. 대부분의 사람들은 코드 재사용을 상속의 주된 목적이라고 생각하지만 이것은 오해다. 인터페이스를 재사용할 목적이 아니라 구현을 재사용할 목적으로 상속을 사용하면 변경에 취약한 코드를 낳게 될 확률이 높다. 상속의 가장 큰 문제점은 캡슐화를 위반한다는 것. 상속의 두번째 단점은 설계가 유연하지 않다는 것 3. 역할, 책임, 협력 코드를 재사용하는 경우에는 상속보다 합성을 선호하는 것이 옳지만 다형성을 위해 인터페이스를 재사용하는 경우에는 상속과 합성을 함께 조합해서 사용할 수 밖에 없다. 객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력이다. 객체지향 설계에서 가장 중요한 것은 책임이다. 객체에게 얼마나 적절한 책임을 할당하느냐가 설계의 전체적인 품질을 결정한다. 역할을 구현하는 가장 일반적인 방법은 추상 클래스와 인터페이스를 사용하는 것 협력의 관점에서 추상 클래스와 인터페이스는 구체 클래스들이 따라야 하는 책임의 집합을 서술한 것이다. 추상 클래스는 책임의 일부를 구현해 놓은 것이고 인터페이스는 일체의 구현 없이 책임의 집합만을 나열해 놓았다는 차이가 있지만 협력의 관점에서는 둘 모두 역할을 정의할 수 있는 구현 방법이라는 공통점을 공유한다. 4. 메시지와 인터페이스 강조하고 싶은 것은 소프트웨어 설계에 법칙이란 존재하지 않는다 라는 것이다. 원칙을 맹신하지 마라. 원칙이 적절한 상황과 부적절한 상황을 판단할 수 있는 안목을 길러라. 설계는 트레이드오프의 산물이다. 소프트웨어 설계에 존재하는 몇 안되는 법칙 중 하나는 경우에 따라 다르다 라는 사실을 명심해라. 프로시저는 부수효과를 발생시킬 수 있지만 반환할 수 없다. 함수는 값을 반환할 수 있지만 부수효과는 발생시킬 수 없다. 5. 객체 분해 하향식은 이미 완전히 이해된 사실을 서술하기에 적합한 방법이다. 그러나 하향식은 새로운 것을 개발하고, 설계하고, 발견하는 데는 적합한 방법이 아니다. 이것은 수학과 아주 유사하다. 수학 교과서는 계산의 과정을 논리적인 순서로 서술한다. 공인되고 증명된 이론이 뒤이은 이론을 증명하기 위해 사용된다....

돈버는 말투, 돈 버리는 말투

Books
2021년 4월 23일

저자는 일본인으로 우리 한국과 일부 사회상이 안맞는 부분이 있긴 하지만 전체적으로 공감할 만한 부분들이 많았고 책도 양이 많지 않아 금방 읽힌 책이었으며, 책을 읽다보면 당연한 소리를 하고있는 것 같지만 그 당연한 것들을 지키기가 어려운 것이기에 공감한 부분들을 이곳에 정리해두려고 한다. 1. 자신의 업무 철학 확립 자신만의 업무 철학을 물었을때는 이것에 대해 깊게 생각해본적이 없어서 대답을 하지 못했는데 이 책에서는 어렵게 생각하지 말고 어떤 점을 가장 신경 써서 일 하는지를 생각해보라고 조언을 했고 나는 그제서야 나만의 업무 철학을 조금씩 세울 수 있었다. (개발에 대한 업무나 일을 해본적이 없기 때문에 이렇다할 철학은 아직 확고하진 않지만 나는 같은 일을 두번 하는 것을 극도로 싫어하기 때문에 한번에 깔끔하고 꼼꼼하게 하는 편이다.)...

5분 와인

Books
2021년 4월 21일

제목에서 그대로 보이듯이 와인에 대해 깊고 많은 역사를 알려주는 책이 아닌 집에서 보관방법, 와인 구매장소, 마트에서 좋은 와인 고르기, 선물용 와인 등 과 같이 가벼운 내용위주의 책들이라 간단하게 보기 좋고 책에서 언급하는 대로 아는 체,있어보이는 척 하기에 괜찮은 책이다. 샴페인을 한번 먹어본 이후로 화이트와인과 스파클링 와인에 빠져서 화이트와인을 만드는 포도 품종이나 지역 등을 한번 공부하고자 읽었고 책의 내용도 가벼우면서 얻고자하는 필요한 내용들은 모두 들어있었고 저자도 뭔가 고상한척 있어보이려고 하지 않고 친근한 어투로 설명해서 간단하게 훑어보기 좋은 책이다....

Clean Code

Books
2021년 1월 22일

1장. 깨끗한 코드 코드 품질을 측정하는 유일한 척도 = 분당 내지르는 ‘WTF!’ 횟수 코드는 요구사항을 상세히 표현하는 수단 ( 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업 = 프로그래밍 ) 작성자가 아닌 사람도 읽고 고치기 쉽고 단순하고 직접적이다 중복을 피하고 한 기능만 수행하게 작제 추상화하기 프로그래밍은 코드를 읽는 시간 대 짜는 시간 비율이 9:1 잘 짠 코드도 시간이 지나면 레거시가 되니 조금씩 코드를 정리/개선하자 2장. 의미있는 이름 클래스/메서드 이름 클래스 : 명사, 명사구가 적합 메서드 : 동사, 동사구가 적합 의도를 명확하게 밝히자 ( 코드의 맥락이 코드자체에 명시적으로 드러내자) 잘못된 정보를 피하자 약어를 함부로 사용하지말자 0/O, l/1등과 같이 서로 헷갈리게 하는 변수명을 짓지말자 의미있게 구분하자 단순히 컴파일러나 인터프리터를 통과할 목적의 네이밍하지 말자 a1,a2와 같이 연속된 숫자나, 불용어를 지양하자 ex getAccount(),getAccounts(), getAccountInfo() 와 같은 메서드가 있다면 새로운 프로젝트 참가자는 메서드를 구분하기 힘들다 발음하기 쉬운 이름을 사용하자 검색하기 쉬운 이름을 사용하자 간단한 메서드에서 로컬 변수는 한 문자를 사용하더라도 상수나 대부분의 변수는 긴 이름이름이 검색하기에도 더 편하다 요즘 좋은 IDE들은 몇자 타이핑 안해도 자동 추천해주니 검색성능 면에서는 긴이름이 더 좋다 인코딩을 피하자 마찬가지로 요즘 IDE들은 코드를 컴파일하지 않고도 타입 오류를 감지할 정도로 똑똑하기 때문에 헝가리안 표기법을 지양 하자 한 개념에 한 단어를 사용하자 fetch/get/retrieve 나 controller/manager/driver와 같이 비슷한 의미의 단어를 혼용해서 사용하는 것을 지양하자 add/insert/append 와 같이 추가하는 메서드라고 하더라고 맥락이 다르면 다른 단어를 사용하자 ( 의도 를 명확하게 밝히는 것이 중요! ) 3장. 함수 가능한 한 작고 한가지 기능만 수행하도록 작성하자....