클린소프트웨어 스터디

소프트웨어 팀이 빠르게 일하고 변화에 반응할 수 있도록 하는 가치와 원칙을 세우기 위해 모인 연합이다. 이들은 연구 끝에 애자일 소프트웨어 개발 선언문을 만들었다.프로세스와 툴보다 개인과 상호작용이 우선이다.포괄적인 문서보다 동작하는 소프트웨어가 우선이다.계약 협상보다

익스트림 프로그래밍(XP)는 애자일 방법 중에서도 가장 유명하다. 단순하면서도 서로 의존적인 실천방법의 집합으로 구성되어 있다. 전체적으로 각 부분에 대해서 간단하게 살펴보자.고객과 개발자가 서로 긴밀하게 작업하면서 서로의 문제를 인식하고 해결고객 : 기능 요소를 정의

개발자는 스토리를 추정하려고 시도하지만 이 추정은 절대적인 것이 아닌 상대적인 것이다. 이런 상대적인 비용을 표현하기 위해 스토리 카드에 그 스토리의 몇몇 포인트를 적는다. 각 스토리 포인트가 어느정도의 시간이 필요할지는 모르지만 대략적으로 스토리 포인트의 양을 통해

단위 테스트를 작성하는 일은 검증의 의미도 있지만 설계의 문제이기도 하다. 또한 문서화의 문제이기도 하다. 테스트 주도 개발 (TDD) 테스트 주도 개발은 프로그램을 설계하기 전에 먼저 테스트를 설계하고, 어떠한 기능을 구현하기 전에 먼저 그 기능에 대한 테스트를

이 챕터는 소프트웨어가 그냥 동작하게 만드는 것과 올바르게 동작하게 만드는 것의 차이에 대해 설명한다. 그리고 코드 구조의 가치와 관련된 내용이기도 하다.리팩토링이란 마틴 파울러가 그의 저서 "리팩토링"에서 아래와 같이 정의한다.외부 행위를 바꾸지 않으면서 내부 구조를

이 챕터에서는 TDD방식으로 진행하며 많은 리팩토링을 하는 하나의 프로그래밍 에피소드를 설명한다. 두 사람이 짝 프로그래밍을 진행하며 대화 형식으로 진행된다. 만들려고 하는 프로그램은 볼링 게임의 스코어를 계산하는 프로그램이다.이 글은 책의 내용을 읽고 정리하는 글이기

잭 리브스는 소스 코드를 표현하는 다이어그램은 설계에서 부수적인 것일 뿐, 설계 그 자체는 아니라고 주장했다. 일련의 UML 다이어그램이 설계의 일부를 나타낼 수는 있지만 설계 자체는 아니다. SW의 설계는 추상적인 개념이다. 그리고 구체적인 모듈, 클래스, 메서드의

톰 드마르코와 메이릴 페이지 존스는 응집도를 모듈 요소 간의 기능적인 연관으로 정의했다. 이번 챕터는 모듈이나 클래스의 변경을 야기하는 응집력에 대해 이야기하고 있다.단일 책임 원칙이란 한 클래스는 단 한 가지의 변경 이유만을 가져야 한다는 원칙이다. 챕터 6장의 볼링

변화를 겪으면서도 안정적이고, 첫 번째보다 오래 남는 설계를 만들려면 어떻게 해야할까..? 버트런드 마이어는 1988년에 개방 폐쇄 원칙(OCP)를 제안하면서 그 해결책을 제시했다.OCP란 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수

Java나 C++이 언어에서 추상화와 다형성을 지원하는 방법 중 하나가 상속이다. 이런 상속의 특별한 사용을 규율하는 설계 법칙은 무엇이고 가장 바람직한 상속 계층 구조는 무엇일까? 그리고 OCP를 따르지 않는 계층 구조를 만들게 해버리는 함정에는 무엇이 있을까? 이러

상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다.추상화는 구체적인 사항에 의존해서는 안 된다. 구체적인 사항은 추상화에 의존해야 한다.어떤 것이 그렇다면 상위 수준의 모듈일까? 중요한 정책 의사결정과 업무 모델을 포함하는 것

사실 ISP는 SRP와 동일한 문제를 해결하는 다른 방식이라고 생각한다. ISP는 그 해결책으로 인터페이스를 분리하는 것을 택한 것이다. 사용하지 않는, 불필요한 메서드를 가진 인터페이스는 오염되었다고 할 수 있다. 그리고 이런 오염된 인터페이스는 불필요한 복잡성과 불

커맨드 패턴은 매우 단순하면서도 사용 범위가 매우 넓은 패턴이다. 커맨드 패턴은 그저 인터페이스 1개로 이루어져있다.일반적인 클래스들은 메서드와 그에 대응하는 변수 집합을 결합한다. 하지만 커맨드 패턴의 경우에는 함수를 캡슐화해서 변수에서 해방시킨다.Command 인터

상속이라는 개념의 등장은 매우 획기적이었다. 유용한 클래스가 있다면 그것의 서브 클래스를 만들고 내가 원하는 부분과 차이가 있는 부분만 수정하여 사용하면 되었다. 상속만으로 코드를 재사용할 수 있었다. 하지만 곧 상속의 문제점이 드러났다. 상속의 과도한 사용은 아주

퍼사드와 미디에이터 패턴은 둘 다 어떤 종류의 정책을 다른 객체들의 그룹에 부과하기 위해 사용한다. 차이가 있다면 퍼사드는 위로부터 정책을 적용하고, 미디에이터는 아래로부터 정책을 적용한다. 또한 퍼사드는 가시적이고 강제적이지만, 미디에이터는 비가시적이고 허용적이다.퍼

이 챕터에서는 단일성을 강제하는 두 패턴을 다룬다. 때때로 이런 단일성이 적용된 객체는 프로그램의 루트가 되기도하고, 다른 객체를 만들기 위해 사용하는 factory가 되기도 하며, 다른 객체를 추적하여 그 객체의 pace에 맞게 동작시키는 관리자가 되기도 한다.책 내

널 오브젝트 패턴 데이터베이스에 "A"라는 이름의 Employee객체를 요청했을 때, 있는 경우는 그 객체를, 없는 경우는 null을 리턴한다. 하지만 우린 null 테스트를 자주 잊어버리고 그로 인해 다양한 에러를 맞이한다. 그렇다면 null을 반한화지 않고 예외

책에서는 간단한 일괄 임금 지급 시스템 개발을 예로 들어 설명하고 있다. 책에서 나오는 "반복의 시작", "구현" 부분에서 내가 느낀 포인트 위주로 정리하려 한다.첫 반복에 선택된 스토리에 대해 간단히 나열한다.요구사항을 듣고 데이터베이스 스키마를 생성하려 하지 말자!

큰 애플리케이션을 조직화할 때는 클래스보다 더 큰 무엇이 필요 → 패키지 이번 챕터에서는 6가지 규칙을 소개 3개 → 패키지 응집도에 대한 원칙, 클래스를 패키지에 할당하는 일을 도움 3개 → 패키지 결합도에 대한 원칙, 패키지 간의 관계를 결정하는 일을

DIP에 따르면 구체 클래스에 의존하는 것은 피하고 추상 클래스에 의존하는 것을 선호해야 한다.사실 new 키워드 사용하면 엄격하게 DIP를 어기는 셈이다.사실 근데 구체 클래스가 쉽게 변경되는 종류의 클래스가 아니라면(String같은) 큰 문제는 없다.하지만 변경되기

패키지 다이어그램은 의존 관계가 아래쪽으로 향하도록 그린다 → 관례적 표현항상 동일한 변화에 동일하게 폐쇄되어 있는지 패키지 점검 (CCP)거의 아무도 A패키지에 의존하지 않는다! → A는 책임이 없는 패키지!A패키지는 어떤 것도 의존하지 않는다! → A는 독립적인 패