# clean software

[03장] 계획세우기
중요한 사용자 스토리를 가능한 한 모두 확정하려고 하지만, 전부는 않는다스토리 카드에 그 스토리 몇몇 포인트만 적음너무 크거나 너무 작은 스토리는 추정하기 어려움스토리가 분할되거나 합쳐지면 다시 추정해야함한두개의 스토리로 프로토타입을 만들어 속도를 예측하는 단계를 스파
[Clean Software] Agile 실천 방법
연합 소프트웨어 개발 선언문 변화에 빠르게 반응하지 못하는 문제를 발견한 전문가들이 변화에 빠르게 반응할 수 있도록 하는 가치와 원칙을 세우기 위해 모였고 다음 선언문을 발표하게 되었다. 프로세스와 툴보다 개인과 상호작용이 우선이다 포괄적인 문서보다 동작하는 소프트
나의 언어로 정리하는 클린 설계 원칙 (SOLID)
SOLID란, 좋은 벽돌로 좋은 아키텍처를 정의하는 원칙이다. 소프트웨어가 변경이 쉽도록, 이해하기 쉽도록, 쉽게 활용될 수 있도록 함을 목표한다.
.png)
애자일 설계란 무엇인가?
소프트웨어 개발 생명주기를 검토한 후, 공학 설계의 기준을 실제로 만족시킬 유일한 소프트웨어 문서는 소스코드 목록뿐임을 알 수 있었다. - 잭 리브스(Jack Reeves)

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

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

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

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

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

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

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

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

Review: 소프트웨어 개발의 지혜 - 15장_FACADE 및 MEDIATOR 패턴
FACADE 패턴은 복잡하고 일반적인 인터페이스를 가진 객체 그룹에 간단하고 구체적인 인터페이스를 제공하고자 할 때 사용한다.예를 들어, 우리가 직접 작성한 어플리케이션에 DB와 연동되어야 하는 Product라는 객체가 있고, DB 연동 작업을 처리할 수 있도록 하는