Agile Object-Oriented Design

1. Agile Object-Oriented Design A&D 발표자 : 김태현 taekwonv@gmail.com

2. 생각해보자 • “나는 디자인 없는 코딩이 쉬워요” • 코딩이 쉬웠던 대가. • 저지르고 땜빵하기의 기나긴 역사 • “돌아가기만 하면 되잖아.” – 성수대교 방식 • 좋은 평가는 저지른 자에게만 • 풍토와 시스템의 문제 • 먹었으면 최소한 설거지라도 하자. (리팩토링) • 안다. 하지만 귀찮다. = 용감한 사람 • OOP 만으로 충분한가? • OOAD 라는 게 있다. Architecture & Design

3. 디자인이란 무엇인가 • Jack 의 문제제기 • 디자인은 제일 먼저 소스코드에 의해서 문서화되고, 다이어그램들은 디자인 그 자체가 아니라 부수적인 것들이다. (소스코드가 곧 디자인이다.) • 모든 소스는 디자인이 있다. 다만 디자인이 있다고 좋은 것이 아니라 좋은 디자인이 있어야 좋은 것이다. • 디자인은 항상 먼저 해야 하는가? • Agile 이 대세다. • 창조와 협업의 시대. • 모든 문제는 인간으로부터 나오고 인간으로만 해결된다. • 다만, 대세라고 해서 영원한 진리는 아니다. 하지만 영원한 진리가 아니라고 해서 못할 이유가 있는가. Architecture & Design

4. Agile Software Design • 디자인은 다이어그램이 아니라 추상적 컨셉이다. • “디자인이 있다.” vs “좋은 디자인이 있다.” • 디자인 활동의 결과로 디자인은 생성된다. • 디자인 활동에는 어떤 것들이 있을까? • ASD는 과정이지, 결과가 아니다. • 원칙,패턴,소프트웨어의 구조와 가독성을 향상시키기 위한 방식을 연속적으로 적용하는 활동이다. • 모든 시점에서 시스템 설계를 가능한 간단, 명료하고 표현적으로 유지하려는 노력이다. Architecture & Design

5. 나쁜 디자인 냄세 • 고구마줄기 : 변경이 힘들다. 한번 고치면 줄줄이 고칠 것이 생긴다. • 젠가 : 뭘 바꾸기만 하면 문제가 생긴다. • 스파게티 : 재사용 부분을 빼내기 힘들다. • 수렁 : 좋은걸 적용하기 힘들고 계속 나쁜 것들만 늘어나기 쉽다. • 미로 : 쓸데없이 너무 복잡하다. • 복사신공 : 비슷한 것들이 자꾸 반복되어 나온다. • 암호 : 읽고 이해하기가 너무 힘들다. Architecture & Design

6. 무엇이 좋은 디자인인가? • 쉬운 것 보다 좋은 것은 없다. • 보기 좋은 떡이 먹기도 좋다. • Robert C. Martin 의 원칙 • SRP (Single Responsibility Principle) • OCP (Open-Closed Principle) • LSP (Liskov Substitution Principle) • DIP (Dependency Inversion Principle) • ISP (Interface Segregation Principle) • 결자해지 원칙 • 일을 벌인 클래스가 그 일을 마무리 해야 함. Architecture & Design

7. SRP (Single Responsibility Principle) • 하나의 클래스가 하나의 책임만 져라. • Example • 네트웍 검사 클래스가 네트웍 검사하고 검사 결과를 윈도우로 띄워주는 책임을 갖고 있는 경우. • 네트웍 검사 클래스는 검사의 책임을 맡고, 결과를 윈도우로 띄우는 책임은 다른 클래스가 맡도록 한다. • 고구마줄기, 스파게티 등 방지. • 하나의 책임만 맡기는 어렵다면 책임의 범위를 넓히되 비슷한 책임을 묶어서 하나의 책임이 훼손되지 않도록 한다. • 다양한 객체를 조립하여 작동을 구현하는 통합클래스는 다양한 책임을 가질 수 있 되 책임의 수와 규모를 최소로 유지하고자 노력해야 한다. Architecture & Design

8. OCP (Open-Closed Principle) • 확장은 개방적, 수정은 패쇄적. • OCP가 잘 지켜졌다면, 새로운 기능을 추가할 때 기존의 코드를 고치는 것이 아니라 단지 새로운 코드를 추가할 것이다. • 전략 • 기본은 Abstraction & Polymorphism. • State, Strategy 패턴 등. • Example : cycle, rect, DrawAll() • Command, Decorator 패턴 등. • 고구마줄기, 젠가, 수렁 등 방지. Architecture & Design

9. LSP (Liskov Substitution Principle) • 서브타입은 항상 베이스 타입이 대신할 수 있어야 한다. • JAVA 및 C++에서 OCP 핵심 키워드인 Abstraction 과 Polymorphism 을 구현 하는 방법 중 하나는 상속이다. • LSP는 결국 OCP 를 가능하게 해준다. • 수렁, 스파게티 등 방지 Architecture & Design

10. DIP (Dependency Inversion Principle) • 하이레벨 모듈은 로 레벨 모듈에 의존해선 안 된다. 둘 다 추상에 의존해야 한다. • 추상이 구체적인 것에 의존해선 안 된다. 구체적인 것은 추상에 의존해야 한다. • Example • 범용 클래스인 소켓 클래스가 특정 프로젝트에 의존적인 클래스를 의존해서는 안 된다. • 고구마줄기, 스파게티, 수렁 등 방지 Architecture & Design

11. ISP (Interface Segregation Principle) • 하나의 뚱뚱한 인터페이스를 수정하면 많은 클라이언트도 수정되어야 한다. • 하나의 인터페이스는 선택과 집중이 뚜렷해야 함. • 클라이언트 의존적,특정적(specific)인 인터페이스를 다른 인터페이스에 넣지 말지어다. • 스파게티, 미로 등 방지. Architecture & Design

12. 결국 • 나쁜 냄새가 없어진다. • 명료하고 간결하다. • 이해하기 쉬워진다. • 마침내 코딩 없이도 추상적 레벨(다이어그램 등)에서 소프트웨어 디자인을 할 수 있다. • 디자인 먼저, 코딩 나중도 가능 • 훌륭한 OO 디자이너의 소양 • OOD 에 정통 • 숙련된 OOP 경험 • 플랫폼 의존적 지식 Architecture & Design

13. Before Demo1 - OOAD • Use Case Driven • Architecture-centric • iterative and incremental Architecture & Design

14. Agile OOD 환경 • 듀얼모니터를 사용한다. • 한 모니터는 UML설계화면, 다른 모니터는 코딩화면으로 개발환경을 구축한다. • 장점 • 설계와 코딩을 동시에 할 수 있어 코드가 항상 설계된 상태로 유지될 수 있다. • 설계와 구현의 괴리가 적어진다. • 설계의 학습이 동시에 일어나서 빨리 교육된다. • UML 모델은 하나만 사용. • Analysis, Design, Implement Model 을 따로 만들지 않고 하나의 모델에서 출발하여 완성해나간다.(일반적인 방법에선 분석,설계,구현 모델이 별도로 있고 각 분석에서 설계로 설계에서 구현모델로 전이해나가며 각각이 추적성을 가진다.) 추적이나 기록이 필요하다면 리파지토리를 이용하면 된다. Architecture & Design

15. Before Demo - Process Architecture & Design

16. Agile OOD Demo • Usecase model Issue • 고객의 요구사항이 무엇인가? • 어떤 품질과 기능들이 필요할까? • Analysis Model Issue • 개략적인 클래스와 전체 구조 도출 • Design Model Issue • 세부적인 클래스들의 역할과 관계 설정 • Implement Model Issue • 코드-클래스다이어그램 상호 작용 • 예제) 네트웍 체크 위자드 • Next, prev, event, role Issue • Activation Issue • Progress UI Issue Architecture & Design

17. 프로세스를 논하다. • OOD 가 만족 되었다. 이제는 프로세스 • 폭포수X. 점진 반복O • 디자인먼저, 코딩먼저에 얽매이지 마라. • 닭과 달걀 • 디자인 하면서 코딩, 코딩 하면서 디자인 • 디자인은 추상적 컨셉. Architecture & Design

18. 소프트웨어 아키텍처를 논하다. • 아키텍처는 품질과 구조의 문제. • 품질속성 • 아키텍처 기반 소프트웨어 개발 • 품질속성 도출 > 전략 수립 > 디자인 과 개발 > 평가와 전이 • 디자인의 결정은 품질속성에 기반한다. • 어떤 디자인을 따를 것인가는 어떤 품질속성을 만족시키는가에 달렸다. • 다양한 영역의 방법론들 • 프로세스 : RUP • 구조 : CBD • 문화 : XP • 개발 : OOT (OOP & OOAD) Architecture & Design