Review - 소프트웨어 개발의 지혜

원칙, 패턴, 실천방법 등도 모두 중요하지만, 이것들이 그 기능을 제대로 발휘하게 하는 것은 바로 인간이다. 프로세스와 기술은 프로젝트의 결과에 이차적 영향만을 미칠 뿐, 일차적 영향을 미치는 것은 인간이다. 따라서 프로젝트를 성공적으로 이끌기 위해서는 협력적이고 자기

익스트림 프로그래밍은 애자일 방법 중 가장 유명한 것으로, 단순하면서도 서로 의존적인 실천방법의 집합으로 구성되어 있다. 이 장에서는 그러한 실천방법들을 전체적으로 살펴본다.고객이란 개발자와 같은 회사에서 일하는 비즈니스 분석가일수도, 사용자를 대신하는 대리인일 수도

이번 장에서는 XP에서 일을 계획하는 방식에 대해 자세히 다룬다.프로젝트 초기에 개발자 팀은 사용자 스토리를 추정하기 위해 고객과 함께 일해야 한다. 이 단계에서의 추정은 절대적이 아닌 상대적으로 이루어져야 한다. 사용자 스토리의 상대적인 비용을 표현하기 위해서 '스토

TDD를 하는 방법은 간단하다. 프로그램을 설계하기 전에 테스트 코드부터 작성하는 것이다. 단순한 방법이지만, 이렇게 함으로써 여러가지 이득을 얻을 수 있다.개발 과정에서 작성하게 되는 모든 코드는 기능을 검증할 수 있는 테스트 코드를 갖게 된다. 빈번하게 변경이 일어

소프트웨어는 고객을 위한 것이지만, 동시에 개발자를 위한 것이기도 하다. 개발자를 위한 소프트웨어라는 측면에서, 소프트웨어는 읽기 쉽고 변경하기 쉬워야 한다. 이 책의 대부분은 읽기 쉽고 변경하기 쉬운 코드를 작성하기 위해 필요한 원칙과 패턴을 소개하고 있지만, 궁극적

설계가 잘못되었을 때 소프트웨어는 다음과 같은 증상을 보인다.경직성 - 설계를 변경하기 어려움취약성 - 설계가 망가지기 쉬움부동성 - 설계를 재사용하기 어려움점착성 - 제대로 동작하기 어려움불필요한 복잡성 - 과도한 설계불필요한 반복 - 마우스 남용불투명성 - 혼란스러

클래스는 단 한 가지의 변경 이유만을 가져야 한다.객체 지향 설계에서 '책임'이란 '변경의 축'을 의미한다. 하나의 클래스가 여러 책임을 떠앉고 있을 경우 이 클래스는 변경에 대한 여러 가지 이유를 가지게 되며, 이는 불필요한 관리 포인트를 증가시켜 코드의 유지보수를

모듈의 동작을 쉽게 확장할 수 있다는 것을 의미한다. 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다.어떤 모듈의 동작을 확장하는 것이 그 모듈의 소스 코드의 변경으로 이어지는 것은 아니다. 한 객체의 변경이 의존관계

위 함수는 LSP를 위반한다. 현재는 Shape라는 기반 클래스를 상속하는 클래스가 Circle 클래스와 Square 클래스 뿐이지만, 이를 상속하는 또 다른 클래스 Triangle이 추가된다면 이 함수에 등장하는 Shape(기반 타입)은 Triangle(하위 타입)로

DIP는 물론 매우 유익한 내용을 담고 있는 객체 지향 설계 원칙이지만, 그 이름에 왜 역전(inversion)이라는 단어가 사용되는지 단번에 와닿지 않을 것이다.(나도 이 책을 읽고 나서야 그 이유를 알게 되었다.) 이는 보다 전통적인 소프트웨어 개발 방법에서는 소프

위 상황은 ISP가 지양하는 바로 그 상황이다. 각각의 Transaction 파생 클래스들은 모두 하나의 UI 인터페이스에 의존하게 되는데, 자신이 사용하지 않는 메소드에 의존하게 될 수 밖에 없으며 UI의 일부 메소드의 변경에 대한 영향이 이 UI에 의존하는 모든 T

COMMAND 패턴은 서로 다른 일을 하는 객체 그룹이 하나의 레벨로 묶이길 원할 때 사용하는 패턴이다. COMMAND 패턴의 핵심은 매우 단순한 인터페이스 하나로 설명될 수 있다.이것은 command 객체 안에 존재하는 do() 함수의 수준을 클래스 수준으로 격상시키

이 장은 상속과 위임의 차이를 전형적으로 보여주는 두 개의 패턴에 대해 다룬다. TEMPLATE METHOD 및 STRATEGY 패턴은 비슷한 문제를 해결하고 보통 호환되어 쓰인다. 그러나 TEMPLATE MEHOD는 문제를 해결하기 위해 상속을 사용하는 반면, STR

FACADE 패턴은 복잡하고 일반적인 인터페이스를 가진 객체 그룹에 간단하고 구체적인 인터페이스를 제공하고자 할 때 사용한다.예를 들어, 우리가 직접 작성한 어플리케이션에 DB와 연동되어야 하는 Product라는 객체가 있고, DB 연동 작업을 처리할 수 있도록 하는

종종 클래스와 인스턴스는 1:N 관계를 가진다. 그리고 인스턴스는 애플리케이션보다 짧은 라이프사이클을 가지며 생성되고 소멸되기를 반복한다.하지만 단 하나의 인스턴스만을 가져야 하는 클래스도 있다. 팩토리 클래스 혹은 매니저 클래스 등이 그 예시인데, 이러한 클래스들은

우리는 위와 같은 null 체크에 대해 익숙하다. 종종 이런 식의 코드는 가독성을 떨어뜨리며 에러가 발생하기 쉽다.이런 경우 NULL OBJECT 패턴을 사용하면 null 검사의 필요를 제거하고 코드를 단순화하는데 도움을 줄 수 있다.NULL OBJECT는 클래스의 정

18장과 19장에서는 간단한 일괄 임금 지불 시스템을 설계하고 구현하는 과정을 소개한다. 이번 장에서는 그 개발 과정의 맨 첫 번째 반복을 보여줄 것이다.다음은 첫 반복에 선택된 사용자 스토리에 관해 고객과 나눈 대화에서 메모한 사항 중 일부이다.몇몇 직원은 시간제로

우리는 11장에서 DIP에 대해 배우면서, 구체적인 클래스에 의존하지 않고 사이에 인터페이스를 하나 두어서 추상화에 의존하도록 하는 방법을 배웠다. 하지만 어떤 클래스 내에서 다른 클래스를 새로 생성해야 할 때는 인터페이스가 존재하더라도 무조건 구체적인 클래스에 의존성

동일하게 취급 받는 파생 클래스가 여러개 있을 때, 이 여러 파생 클래스를 멤버 변수로 두고, 똑같은 기반 클래스를 상속하는 COMPOSITE 클래스를 만들 수 있다. 이 패턴의 사용은 단순하지만 가져올 수 있는 이득은 크다.앞서 COMMAND 패턴에 대해 소개하면서

OBSERVER 패턴은 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다.디지털 시계 구현을 예시로 OBSERVER 패턴을 알아보자.

ABSTRACT SERVER 패턴은 디자인 패턴 가운데 가장 단순한 패턴으로, DIP를 지키기 위해 가장 첫 번째로 적용해볼 수 있는 방법이다. 이전의 숱한 예시에서도 익숙하게 사용해 왔던 방식인데, 상위 모듈이 구체적인 하위 모듈에 의존하도록 하지 않고 사이에 인터페

소프트웨어 시스템에는 많은 경계와 장벽이 있다. 프로그램에서 데이터베이스로 데이터를 옮기는 것은 데이터베이스의 장벽을 넘는 것이며, 한 컴퓨터에서 다른 컴퓨터로 메시지를 전송하는 것은 네트워크의 장벽을 넘는 것이다.PROXY 패턴은 우리가 집중하려는 핵심 비즈니스 로직