애자일 개발

인간관계는 복잡할 뿐만 아니라 그 파급 효과가 절대로 깔끔하고 명확하지 않지만 업무의 어떤 측면보다 더 중요하다. 

원칙, 패턴, 그리고 실천방법은 중요하다. 하지만 이것들이 제대로 기능하게 하는 것은 바로 인간이다. 위 구절 바로 다음에 나온는 문장이다.

인간보다는 사람이라 표현하는 것이 더 와 닿는다. 항상 생각하지만 사람의 중요성을 다시한번 생각하게 해 주었다.

기술적 조언을 하고자 하는 책에서 사람을 강조한다는 것은 상식적이지만 중요한 것을 잊지말라는 조언으로 느껴졌다.

올해 초 읽은 ‘행복의 기원’이라는 책에서 사람은 생존 수단이라는 문장이 있었다. 즉 내가 살기위해 사람이 필요하며 곧 사람 관계 속에서 삶의 의미를 느낄 수 있다고 말한다.

한편, 원칙, 패턴 등 기술 습득은 발전하는 삶을 위해 필수 적이며 발전하지 않으면 도태된다.

사람과 기술 모두 중요하지만 책에서는 사람이 먼저라는 말을 하고 있다. 무척 공감한다.

애자일 소프트웨어 개발 선언문

프로세스와 툴보다 개인과 상호작용이 우선이다.
포괄적인 문서보다 동작하는 소프트웨어가 우선이다.
계약 협상보다 고객 협력이 우선이다.
계획을 따르는 것보다 변화에 대한 반응이 우선이다.

왼쪽 항목 각각에도 가치는 있지만, 오른쪽 항목에 가치를 더 부여한다.

마지막 항목을 보고 변화를 더 적극 수용하도록 해야겠다고 생각했다.

테스트 주도 개발 효과

테스트가 아주 이른 시기에 주요한 설계이슈를 명백히 할 수 있다.
동작을 검증하는 테스트를 갖게되어 부주의한 실수를 예방할 수 있다.
테스트들은 프로그램 정상동작을 보증하여 자유롭게 프로그램 수정을 할 수 있다.

리팩토링

모든 소프트웨어 모듈에는 세 가지 기능이 있다.

기능, 변경, 읽는 사람과의 의사소통 이다.

기능은 존재 이유이며, 변경이 쉬워야하고, 읽는 사람이 쉽게 이해할 수 있어야한다.

3가지중 한가지라도 잘못 되었다면 망가진 것이며 수리가 필요하다.

리팩토링은 이 세가지 기능에 있어 도움을 준다.

모듈을 읽기 쉽고 변경하기 쉽게 만듦으로써 기능의 오류를 줄여준다.

읽기 쉽고 변경하기 쉽게 만들기 위해서는 단순한 원칙과 패턴 이상으로 주의력 훈련과, 미를 창조하기 위한 열정이 필요하다.

애자일 설계

변화를 예상하라

요구사항의 변경으로 프로그램은 엉망이 되기 십상이다. 그리고 엉망이된 프로그램은 요구사항 변경때문이라고 탓할 수도 있다. 그러나 이런 변명은 소프트웨어 개발에서 가장 중요한 요소중 하나를 무시한 말이다.

요구사항은 언제나 바뀐다!

이는 우리가 개발자로서 받아들여야 하는 사실이다! 우리는 변하는 요구사항의 세계에 살고 있고, 우리가 만든 소프트웨어가 이런 변화 속에서 살아남을 수 있게 만드는 것이 바로 우리가 해야 하는 일이다.

만약 소프트웨어의 설계가 요구사항 변경 때문에 퇴화한다면, 우리는 애자일 방식대로 하고 있지 않은 것이다.

SOLID

SOLID 모든 원칙은 명백한 부분을 제외하고는 앞서 예상하지 않고 실제 변경이 발생할 때 적용 한다.

Single Responsibility Principle
- 가장 간단한 원칙이면서 제대로 적용하기 가장 어려운 원칙. 책임의 결합은 우리가 너무나 자연스럽게 행한다. 다른 원칙 또한 곧 이 문제로 돌아온다.
- 책임은 애플리케이션이 어떻게 바뀌느냐에 달려 있다. 예상하기 어려운 변화의 경우 경직성과 불필요한 복잡성 사이에서 경직성을 선택하되 변경이 실제로 일어 났을때 바로 분리한다.
Open Closed Principle
- OCP는 비용이 많이 든다. 따라서 OCP의 응용이 있을 법한 변경 정도로 제한하고 변경이 일어날 때까지 기다린다!
- 어설픈 추상화를 피하는 일은 추상화 자체만큼이나 중요하다.
Liskov Substitution Principle
- 서브타입은 그것의 기반 타입으로 치환 가능해야 한다.
- 상속은 IS-A관계는 클라이언트가 의존하는 행위에 관한 것이다.
- 다형적인 행위에 있어 미묘한 결점을 놔두는 것이 적절한 대응인 경우도 드물게 있다. 완벽을 추구하는 대신 타협안을 받아들이는 것은 공학적인 균형이다. 단, 가볍게 원칙을 포기해서는 안 된다.
Interface Segregation Principle
- 클라이언트가 자신이 사용하지 않는 메소드에 의존하도록 강제되어서는 안 된다.
- 비대한 클래스의 인터페이스를 클라이언트 고유의 인터페이스 여러 개로 분리해야한다. 이렇게 하면 호출하지 않는 메소드에 대한 클라이언트의 의존성을 끊고, 클라이언트가 서로에 대해 독립적이 되게 만들 수 있다.
Dependency Inversion Principle
- 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안 된다. 둘 모두 추상화에 의존해야 한다.
- 추상화는 구체적인 사항에 의존해서는 안 된다. 구체적인 사항은 추상화에 의존해야 한다.
- 전통적인 절차 지향 프로그래밍 방식은 정책이 구체적인 것에 의존하는 의존성 구조를 만든다. 이런 경우 정책 변경에 따라 프로그래밍도 같이 변한다. 객체지향 프로그래밍은 이런 의존성 구조를 역전시켜 변경을 효과적으로 반영한다.
- 의존성 역전의 원칙은 객체 지향 기술에서 당연하게 요구되는 많은 이점 뒤에 있는 하위 수준에서의 기본적인 메커니즘이다.