스프링보다 중요한 스프링 이야기
•
278 j'aime•12,759 vues
2015/4/23일 OKKY 정기 모임에서 발표한 자료입니다. 클린코드 11장과 12장의 내용을 기본 틀로 해서 내용을 구성해 봤습니다. 스프링을 이용해서 생성과 이용의 관심사 분리, 횡적 관심사 분리를 하게 되면 지속적으로 SW를 개선할 수 있다는 내용입니다.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 스프링보다 중요한 스프링 이야기
Similaire à 스프링보다 중요한 스프링 이야기 (20)
Plus de Sungchul Park
Plus de Sungchul Park (18)
스프링보다 중요한 스프링 이야기
- 1. 스프링보다 중요한 스프링 이야기 박성철 (한국 스프링 사용자 모임; KSUG)
- 2. 生卽苦
- 3. 좋은 SW란?
- 4. 좋은 SW란? 기능 품질 구조 품질
- 5. 신규 기능 추가 기능 구현 + 통합 “우린 못해!” “우린 안해!”
- 6. 소프트웨어 위기 소프트웨어 위l의 주요한 위lr 컴퓨터 성능이 몇 수십 배나 더 강력해졌기 때문입st! 심하게 말하면, 컴퓨터가 없었을 r 프로i래밍에r 전혀 문제가 없었습st( q린 컴퓨터 몇 개 뿐이었을 r 프로i래밍이 조k 문제가 되었 c, 이제r 거v한 컴퓨터에 프로i래밍x 따라서 거v한 문제가 되었습st( ' 에츠허르 w이크스트라 / 1.-, 01M 튜링상 수상 연설 F. L. 바우어(Fritz Bauer), 1968, 나토 SW 공학 학회 http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/index.html
- 7. 인텔 CPU 클럭 속도 향상 속도
- 8. 미녀라고 하더니…
- 9. SW 위기 SW 개발 문제 SW 품질 문제 SW 기능 문제 SW 구조 문제 보이는 문제 숨은 문제
- 10. SW 개발 문제 SW 기능 문제 SW 구조 문제 보이는 문제 숨은 문제 테스트 설계 & 아키텍처 개발 방법론
- 12. 관심사 분리 (Separation of concerns) Edsger W. Dijkstra, 1974, "On the role of scientific thought” “e심사 분리r, 완벽하지r 않t 해x, 아직은 ph가의 생각을 효율 적으로 정리하rw 사용할 수 있r 유일한 l법이t(” “sepaKaMCoG o@ coGceKGs X eOeG C@ GoM peK@ecMly possCble Cs yeM Mhe oGly aOaClable MechGCJue @oK e@@ecMCOe oKdeKCGA o@ oGe’s MhouAhMs” “특정 e점에 주의를 집중함” “@ocusCGA oGe's aMMeGMCoG upoG some aspecM”
- 13. SW 구조
- 15. 코드 한 덩어리
- 16. 수평적 분리 표현 계층 애플리케이션 계층 도메인 계층 데이터 접근/시스템 통합 계층
- 19. 수평/수직적 분리 AaaControl XxxService AbcBiz QazDao BbbControl WsxDao CccControl YyyService EdcDao DddControl ZzzService RfvDao DefBiz GhiBiz JklBiz MnoBiz 사용자 인터페이스 모델 쓰임새(Use Case) 모델 데이터 모델
- 20. 객체 지향 프로그래밍
- 21. 객체지향 프로그래밍 동적 디스패치 캡슐화 서브타입 다형성 객체 위임 상속 Open Recursion 클래스 인스턴스 메서드 추상화
- 22. 다이나믹 디스패치 ≒ 메시징 “m게 OO7r 메시징d 상태 처리 d정의 지역적 보존, 보호, 은익d 모든 것의 극u적인 지연 바인딩 뿐이t(” “OO7 Mo me meaGs oGly messaACGA, local KeMeGMCoG aGd pKoMecMCoG aGd hCdCGA o@ sMaMe'pKocess, aGd exMKeme laMe'bCGdCGA o@ all MhCGAs” “중요한 착안은 “메시지”이t( 이r 스몰톡d 스퀵 핵심 의 본질이t( 일본어에 마(ま)라r 짧은 u어가 있t(” “9he bCA Cdea Cs “messaACGA" MhaM Cs PhaM Mhe keKGal o@ SmallMalk)SJueak Cs all abouM( 9he JapaGese haOe a small PoKd Tma’(((” 앨런 케이(0laG Kay) 間
- 23. 순서도 vs 소통도 (flow chart vs communication diagram)
- 24. 메시지 대면 대화 X 지인과의 전화 통화 X
- 26. invokeinterface 자바의 네(다섯)가지 호출 방식 invokestatic invokespecial invokevirtual invokedynamic 안o 친f야( 이것 좀 부탁해( n가 ph지 몰라x 신분은 아s 이것 좀 처리해줘( n가 ph지 x무지 모르겠지만 이것 좀 처리해줘(
- 27. 인터페이스 중심 설계 “7KoAKammCGA Mo aG CGMeK@ace,SGoM aG CmplemeGMaMCoG” 2o@ 디자인 패턴 X 설계 구현 역할
- 28. 의존관계 역전 원칙 (Dependency inversion principle; DIP) AbcService X SomeRepository SomeDao 서비스 계층 데이터 접근 계층
- 29. 생성과 사용 분리 (Separation of Use from Construction)
- 30. 객체 생성 문제 malloc() new ? GRASP의 생성자(creator) 원칙 누가 객체를 생성해야 하나? 대상 클래스로 구성되는 클래스 대상 클래스를 담고 있는 클래스 대상 클래스의 인스턴스를 기록하는 클래스 대상 클래스와 가깝게 사용되는 클래스 대상 클래스를 생성하는데 필요한 데이터가 있는 클래스 5A A G
- 31. 9AN J N G
- 32. 1NN A
- 33. :JB R A
- 34. GAN
- 35. 객체 생성과 구현 의존 문제 사용 생성 구현에 의존 Servicesvc=newAwesomeService(); svc.showMeTheMoney(); AwesomeService Service
- 37. 복잡한 의존 관계 문제 No man is an island entire of itself; every man is a piece of the continent, a part of the main; 사용 생성 ?
- 38. 애플리케이션 구성
- 41. 객체 메시지 (역할) 데이터 로직(구현) 인터페이스
- 42. Acme Processor AcmeUI AcmeLogic AcmeDAO
- 43. AcmeUI AcmeL ogic AcmeD AO RealAcmeLogic RealAcmeDAO 인터페이스 클래스 예) Acme Processor 인터페이스를 사용한 설계 DIP
- 44. AcmeUI AcmeL ogic AcmeD AO RealAcmeLogic DevAcmeDAO 예) Acme Processor 개발용
- 45. AcmeUI AcmeL ogic AcmeD AO FakeAcmeLogic X 예) Acme Processor UI 테스트용
- 47. 추상 공장 패턴 사용 생성 공장1 공장2 공장3 + = + = + = 구성1 구성2 구성3 생 성 요청 구현 구현
- 48. 의존성 주입 (Dependency Injection) 사용 생성 구성 메타 데이터 1 구성 메타 데이터 2 구성 메타 데이터 3 구성1 구성2 구성3 DI 프레임워크 + + +
- 49. 점진적인 성장
- 51. D N/ RRR BG F J DJ JN GA A J ((- )., ,
- 52. 설계 시점 2
- 53. AN
- 54. ;
- 55. 4 J “시스템 설계에 매일 투자하라( ((( 현재 설b가 여러분이 이해한 최선의 설b와 일치하x록 점진적이면서x 지속적으로 작업한t(” ' 켄트 벡 폭포수 근본주의 BDUF(포괄적 사전 설계) DUF 창발적 설계 막 개발 YAGN!!! JP
- 56. 1 U
- 57. 5J
- 58. 7AA
- 60. 설계 = 소스 코드 J
- 61. N
- 62. J
- 63. JP
- 64. P G
- 65. NJB R A0
- 66. J
- 67. N
- 68. JP
- 69. AN
- 70. NJB R A
- 72. B G
- 73. NJP A
- 74. J A
- 75. N
- 76. DA
- 77. A G
- 78. NJB R A
- 79. AN
- 81. DA
- 82. AS AN
- 83. NJ A
- 84. JB
- 85. DA
- 86. J NA PA AN
- 87. JB
- 88. D
- 89. NNP J
- 91. 6 F
- 92. 9AA AN • 테스트 가능(Testable): 작은 테스트 가능한 단위 • 이해 가능(Understandable): • Browsable • Explainable TUBE
- 93. OOP/D 5원칙(SOLID) 단일 책임 원칙(Single responsibility principle) e
- 94. h
- 95. qd
- 96. tY k
- 99. v
- 100. a
- 102. b
- 104. ’
- 105. r
- 107. tY
- 109. a
- 110. 리스코프 치환 원칙(Liskov substitution principle) l i
- 112. y
- 113. fn
- 114. px
- 117. l
- 118. c
- 121. a
- 122. 인터페이스 분리 원칙(Interface segregation principle)
- 123. g m
- 128. s
- 130. u a
- 131. a
- 132. 의존관계 역전 원칙(Dependency inversion principle) w
- 134. o
- 135. w
- 137. GRASP 일반 책임 할당 소프트웨어 원칙(또는 패턴) Information Expert Controller Creator High Cohesion Low Coupling Indirection Pure Fabrication Polymorphism Protected Variations http://en.wikipedia.org/wiki/GRASP_%28object-oriented_design%29
- 138. 설계 패턴 크리스토퍼 알렉산더: 패턴 창안 켄트 벡 워드 커닝햄: SW에 패턴 도입 (OOPSLA 1987) 에릭 감마, 리처드 헬름, 랄프 존슨, 존 블리시데스: 디자인 패턴 출판 Creational patterns Structural patterns Behavioral patterns
- 139. 템플릿 메서드 패턴
- 140. 전략 패턴
- 141. 관찰자 패턴
- 142. 파사드 패턴
- 144. 테스트 자동화 Fast: 테스트는 수행 속도가 빨라서 테스트에 부담이 없어야 한다. Independent: 테스트는 서로 영향을 주지 않고 독립적으로 순서에 상관 없이 실행될 수 있어야 한다. Repeatable: 테스트는 어떤 환경에서도 반복해서 실행할 수 있어야 한 다. Self-Validating: 테스트는 사람이 관여하지 않고도 결과를 알 수 있도 록 참과 거짓이 분명해야 한다. Timely: 테스트는 적시에 작성해야 한다. 구현 바로 직전이 최적이다. F.I.R.S.T 수시로 리팩터링을 수행하면서 점진적으로 설계를 개선하도록 도와주는 안전장치
- 145. 창발적 설계 - 코드 속 설계의 발굴 - 효과적인 추상화 - 기술적 추상화 - 문제 도메인 추상화 - 관용적 패턴 수집
- 146. 진화하는 아키텍처 “i 아키텍트들이 왔t( i들은 X7가 프로i래머들한테r 좋을지 몰라x, 아 키텍처를 프로젝트 초기의 어느 단계에서 설계할 수 있x록 해준t면 모든 일이 훨씬 부드럽게 진행될 거라c 설명했t( 사람들은 이에 v해, 흐름을 옹호해야 하며, 아키텍트 역시 흐름 원칙에 따라서 처음에r 아키텍처를 시작하l 충분할 정x로만 만들c 일을 진행하면서 꾸준히 다듬어가야 한tr 주장을 아키텍트 들에게 퍼부었t( ag i들은 마지못해 i렇게 하겠tc y의했지만, i래x 아키텍처 ub가 따로 있r 만큼 좋지r 않을 것이라c 말했t(” ? 익스트림 프로i래밍, 71,0, “전체 X7팀”에서
- 147. 횡단 관심사 로직 A 로직 B 로직 C 로직 D 캐시 인자 확인 트랜잭션 관리 로그 기록 인증 오류 차단 관심사 분리 대상 - 서로 다른 여러 추상 경로에 횡단으로 걸친 중복 - 분해하기 불가능 하거나 어려움 - 강한 결합 - 반복적인 다량의 코드 양산 - 낮은 코드 재사용, 가독성의 원인
- 148. 관점 지향 프로그래밍 • 횡단 관심사의 중앙 집중 • 메서드 호출을 가로채어 처리 • 새로운 행위를 추가 • 재사용성 향성 • 가독성 향상 횡단 관심사를 분리함으로서 모듈화를 고도화 하려는 기술
- 149. 스프링 프레임워크
- 150. 스프링 프레임워크는… Java EE w/o EJB Java Application Framework
- 151. 스프링 프레임워크는… 스프링 프레임워크는 자바 플렛폼으로서 자바 애플리케 이션을 개발하는데 필요한 하부 구조를 포괄적으로 제공 합니다. 스프링이 하부 구조를 처리하므로 개발자는 애플 리케이션 개발에 집중할 수 있습니다. Spring Framework is a Java platform that provides comprehensive infrastructure support for developing Java applications. Spring handles the infrastructure so you can focus on your application.
- 152. Java EE • Java EE는 다량의 배관 코드를 요구한다. • 많은 Java EE 관련 패턴은 Java EE의 단점 때문에 생겼다. • Java EE는 테스트가 힘들다. • Java EE는 개발자가 쓰기에는 적당하지 않다. 이런 문제에도 불구하고 Java EE는 풍부한 개발 기반을 제공한다. Java EE를 추상화해서 개발자가 편하게 사용할 수 있는 추상화 계층 필요
- 153. 봄(스프링)의 대삼각형 순수 객체 (POJO) 의존 관계 주입 DependencyInjection 관점 중심 프로그래밍 AspectOrientatedProgramming 이식 가능한 서비스 추상화 Portable Service Abstraction 애플리케이션 구성 횡단 관심사 분리
- 154. 순수 객체 (POJO) 의존 관계 주입 DependencyInjection 관점 중심 프로그래밍 AspectOrientatedProgramming 이식 가능한 서비스 추상화 Portable Service Abstraction 봄(스프링)의 대삼각형
- 155. 육각형 아키텍처
- 156. 인프라의 침투 유지 보수 어려움 테스트 장애 개발 속도 저하 결함 급증
- 157. 비 침투적 스프링 POJO (순수 객체) 차단
- 158. 스프링 모듈
- 159. 스프링의 특징 • 관심사 분리를 통한 로직 순수성 유지 (비침투성, POJO, DI, AOP) • 컴포넌트 기반 애플리케이션 구성 • 컴포넌트 생애 관리 • Effective Java • 테스트 용이성 • 각종 자바 EE 기술 통합 • 자바 EE 추상화를 통한 생산성 향상 • 메타프로그래밍 창발적 설계 진화하는 아키텍처 지원
- 160. 2000년 대 후반 이후의 변화 • 소비자 시장 개발 기술의 기업 시장 진출 시도 • 생산성 경쟁 • 클라우드 보급(IaaS, PaaS, SaaS) • 무어의 법칙 종료, 멀티 코어 CPU 시대 • 빅 데이터/패스트 데이터 • 시스템 통합
- 161. 스프링 IO 플랫폼
- 162. 클린 코드, 11장 “시스템” + 12장 “창발성”