James Song's Blog

차례 1장. 형식 연역 2장. auto 3장. 현대적 C++ 적응하기 4장. 똑똑한 포인터 5장. 오른값 참조, 이동 의미론, 완벽 전달 6장. 람다 표현식 7장. 동시성 API 8장. 다듬기 Item 23: std::move와 std::forward를 숙지하라 기억해 둘 사항들 - std::move는 오른값으로의 무조건 캐스팅을 수행한다. std::move 자체는 아무것도 이동하지 않는다. - std::forward는 주어진 인수가 오른값에 묶인 경우에만 그것을 오른값으로 캐스팅한다. - std::move와 std::forward 둘 다, 실행 시점에서는 아무 일도 하지 않는다. Item 24: 보편 참조와 오른값 참조를 구별하라 기억해 둘 사항들 - 함수 템플릿 매개변수의 형식이 T&& 형태이고 T가..

많은 개발자들이 테스트 주도 개발이 좋다고 얘기한다. 그러나 막상 처음으로 프로젝트에 적용하려 하면 어떻게 시작해야 할지 막막하고 여러 난관에 부딛치게 된다. 테스트 도구는 무엇을 쓸 것인가? 레거시 코드의 의존성은 어떻게 깰 것인가? 어떻게 팀 개발 문화에 정착시킬 것인가? NDC 2013에서 홍종찬 님의 발표는 다른 개발자들은 테스트 주도 개발을 어떻게 실무에 적용해서 잘 사용하고 있을까라는 내 궁금증을 어느 정도 풀어줬다. 그리고 덕분에 그동안 미뤄오면 마이클 페더스의 도 읽는 계기가 됐다. 목차 1. GoogleTest를 써라 2. 의존성을 끊어라 3. 시행착오로 얻은 행동요령들 참고 Google Test https://github.com/google/googletest null object 패턴..

데이비드 실즈의 책 제목처럼 우리는 언젠가 죽는다. 어느 누구도 피할 수 없는 진실이다. 하지만 우리는 너무 쉽게 이 사실을 망각하며 살아간다. 내 인생의 끝이 언제인지 알 수 있다면 남은 시간을 계획적으로 더 가치있게 쓸 수 있을까? 어쩌면 언제 끝날지 모르는 삶의 불확실성 때문에 더더욱 오늘 하루 지금 이 순간을 가치있게 보내야 하는지도 모르겠다. 이 책을 읽으면서 훌륭한 의사이자 작가 폴 칼라니티를 알게 되었는데 이제 더 이상 그의 책도 그의 소식도 접할 수 없다니 안타깝다. 칼라니티에게 간절했던 건강한 하루 한 달 일 년을 지금 살고 있다는 사실을 잊지 않고 싶다. 아름다운 이 책의 제목처럼 그의 영혼은 숨결에서 바람이 되어 이 책을 읽는 사람들의 가슴속에 남아 특별한 가르침을 주고 있는 것 같다..

8장. 특징, 어떻게 추가할까? 8.1. 테스트 주도 개발 테스트 주도 개발은 다음과 같은 순서로 진행한다. 1. 실패 테스트 케이스를 작성한다. 2. 컴파일되게 만든다. 3. 테스트에 통과하도록 만든다. 4. 중복을 제거한다. 5. 반복한다. TDD와 레거시 코드 한 번에 한 작업만 집중하도록 해주는 것은 TDD의 가장 중요한 역할 중 하나이다. TDD를 적용하면 코드 작성이나 리팩토링 과정에서도 두 작업을 함께 하는 경우는 결코 일어나지 않을 것이다. 레거시 코드에 있어서 분리는 특히 중요하다. 분리를 통해 새로운 코드를 작성할 때 다른 새로운 코드와의 독립성을 유지할 수 있기 때문이다. 새로운 코드를 작성하고 나면 리팩토링해서 새로운 코드와 이전 코드 사이에 있는 중복을 제거할 수 있다. 8.2. ..

7장. 코드 하나 바꾸는데 왜 이리 오래 걸리지? 제대로 유지되는 시스템과 레거시 시스템 간 차이점 적절히 유지된 시스템인 경우 어떻게 변경시키는지 알려면 오랜 시간이 걸릴지 모른다. 하지만 일단 어떻게 할지를 알고 나면 변경 자체는 매우 간단할 뿐만 아니라 변경 후 시스템이 휠씬 편안하게 느껴질 것이다. 레거시 시스템인 경우에는 무엇을 해야 하는지 이해하는데 오랜 시간이 걸릴 것이고 변경 자체도 힘든 과정이 될 것이다. 의존관계 깨기 의존관계를 깰수록, 그리고 클래스들을 새로운 패키지나 라이브러리로 이동시킬수록 시스템 전체 재빌드하는 비용은 늘어나지만, 빌드에 걸리는 평균 시간은 줄어들 것이다. Opportunity handling 클래스들 ConsultantSchedulerDB 클래스에 대한 구현체 ..

6장. 고칠 건 많고 시간은 없고 6.1. Sprout Method Sprout 메서드를 만드는 순서 어느 부분에 코드 변경이 필요한지 식별한다. 변경이 한 메서드 안의 한 부분에 있는 단일한 일련의 스테이트먼트라면, 관련 작업을 하는 새로운 메서드를 호출하는 코드를 작성한다. 그리고 주석을 표시한다. 소스 메서드에 어떤 지역 변수들이 필요한지를 결정하고 호출에 필요한 매개변수를 만든다. Sprout 메서드가 소스 메서드에 값을 반환해야 할지 결정한다. 값을 반환해야 한다면 호출을 변경시켜 반환된 값이 변수에 할당되도록 한다. 테스트 주도 개발 방법을 사용해 sprout 메서드를 개발한다. 호출이 동작하게 만들기 위해 소스 메서드에 있는 주석문을 제거한다. 6.2. Sprout Class Sprout 클..

코드가 얼마나 훌륭하게 작성되어 있는지 여부와는 상관없이 테스트 루틴이 없는 코드는 불량 코드다. 얼마나 멋지게 작성되어 있는가와 객체지향의 사용 여부, 그리고 캡슐화의 정도도 참작 요소가 전혀 되지 못한다. 테스트 루틴이 있으면 코드의 동작을 빠르고 검증 가능하게 변경시킬 수 있다. 하지만 테스트 루틴이 없으면 실제로 우리 코드가 더 나아지는지 더 나빠지는지를 알 수 없게 된다. 1장. 소프트웨어 변경 소프트웨어를 수정하는 네 가지 이유 1. 새로운 특징을 추가한다. 2. 버그를 제거한다. 3. 소프트웨어 설계를 개선한다. 4. 자원 이용률을 최적화한다. 특징 추가 버그 수정 리팩토링 최적화 구조 변경시킴 변경시킴 변경시킴 - 기능 변경시킴 변경시킴 - - 자원 이용률 - - - 변경시킴 위험한 변경 ..

틈 오쇼 라즈니쉬 저/나혜목 역 과거와 미래 사이에는 영원으로 통하는 틈이 있는데, 그것이 바로 '현재'이다. - James Song

"비트코인 마이너와 구글 데이터센터의 공통점은 무엇일까요?" 위와 같은 질문으로 시작하는 는 비동기 처리를 통해 성능을 향상시킬 수 있는 함수형 리액티브 프로그래밍 페러다임의 철학과 개념에 대해서 주로 설명한다. 시간(응답성)의 개념과 함께 우리가 왜 컨트롤 흐름 방식에서 데이터 흐름 방식으로 프로그래밍 패러다임을 변화해야 하는지 설명하는 부분은 흥미롭다. 아래 리액티브 선언에서는 네 가지 속성으로 표현했지만 데이터 흐름 방식의 패러다임의 목적은 결국 빠른 응답성으로 귀결된다. Reactive Manifesto - Responsive - Elastic - Resilient - Message Driven Event-Driven 방식의 리액티브, 함수형 프로그래밍의 모나드, Rx의 개념을 알기 쉽게 설명해 ..

구글의 미래 토마스 슐츠 저/이덕임 역 는 독일의 기자 토마스 슐츠가 쓴 구글에 대한 기록이다. 그는 좀처럼 외부에 문을 열지 않는 구글의 내부를 독점적으로 취재할 수 있는 기회를 얻어 기자답게 발로 뛰어가며 이 책을 완성했다. 구글에 대한 이야기는 다른 매체를 통해 이미 많이 소개되었지만 이 책만큼 그 내부의 움직임을 알기 쉽게 잘 정리한 책을 있을까 싶다. 책 속에 등장하는 수많은 구글의 경영진과 엔지니어들의 인터뷰 내용은 책의 재미와 디테일을 더한다. 구글의 미래 프로젝트를 통해 IT 기술이 앞으로 어떻게 흘러갈 것이지 큰 그림을 볼 수 있는 의미 있는 책이다. (※주의※ 신세 한탄으로 이어질 수도 있으니 구글 기업 문화에 대한 부러움은 잠시 접어두고 읽어야 한다.) 목차 제1장 그라운드 : 학교 ..