Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

변경에 강한 애플리케이션, 유기적 애플리케이션

3,421 views

Published on

유기물처럼 변화에 대응하는 애플리케이션을 개발하려면 가장 먼저 바꾸어야 하는 SW 개발에 대한 심상을 얘기해 봅니다.

Published in: Software
  • Be the first to comment

변경에 강한 애플리케이션, 유기적 애플리케이션

  1. 1. 유기적 애플리케이션 SW 개발에 대한 관점 바꾸기 ‑ 박성철 ‑
  2. 2. 生卽苦 (생 즉 고)
  3. 3. SW 개발이란?
  4. 4. 공장 테일러리즘(과학적 관리법) 생산 수단은 회사 소유 단순 근로자
  5. 5. 공장 같은 개발
  6. 6. 인공물
  7. 7.  
  8. 8.  
  9. 9.  
  10. 10.  
  11. 11. 생물 같은 인공물
  12. 12.  
  13. 13.  
  14. 14.  
  15. 15.  
  16. 16. 생물의 특징 번식(복재) 세대 반복, 유전 진화 성장, 변태 회복
  17. 17. 생물의 생존 “결국 살아남는 종은 강인한 종도 아니고, 지적 능력 이 뛰어난 종도 아니다. 변화에 가장 잘 대응하는 종 이 종국에는 살아남는 것이다.”  ‑ 찰스 다윈
  18. 18. 변화 “The only thing that never changes is that everything changes.” ― Louis LʹAmour
  19. 19. SW 유지보수란? 교정적 유지보수: 21.7%  긴급 수정(12.4%), 정규 수정(9.3%) 적응적 유지보수: 23.6%  데이터 규격 변경(17.4%), H/W 변경(6.2%) 완성도 향상 유지보수: 51.3%  요구 사항 변경(41.8%), 문서화(5.5%), 최적화(4%) 기타(예방적 유지보수 포함): 3.4%
  20. 20. 변화 준비 “너무 크고 꼬여있거나 복잡해서 유지 보수가 더 이 상 악화될 수 없는 코드는 없다.”  ‑ 제랄드 와인버그 SW의 변화는 필연 의식적이고 계획적인 대응 필요 변화를 진화의 기회로 활용 가능 내적인 질의 향상 유도
  21. 21. 설계
  22. 22. SW 설계
  23. 23. 분해(Decomposition)?
  24. 24. 리팩터링
  25. 25. 리팩터링 “소프트웨어를 보다 쉽게 이해할 수 있고, 적은 비용 으로 수정할 수 있도록 겉으로 보이는 동작의 변화 없이 내부 구조(?)를 개선(?)하는 것”
  26. 26. Re‑factor‑ing factoring = decomposing
  27. 27. 테스트 자동화와 리팩터링
  28. 28. 테스트 주도 개발 TDD 주기 1.  실패하는 테스트 작성 2.  통과하는 코드 작성 3.  리팩터링 점진적인 테스트 보강
  29. 29. TDD의 리팩터링 TDD = 점진적으로 테스트와 구현을 추가 열린 설계 완성된 SW보다 만족시켜야 할 테스트 수가 적음 훨씬 과격하고 큰 변화가 가능한 리팩터링 TDD = 테스트 주도 설계(Test Driven Design)
  30. 30. 테스트 주도 설계 TDD를 설계관점에서 바라봄 단순한 TDD 주기에서 설계가 창발 적절한 추상화(YAGNI!) 최적의 설계
  31. 31. 창발적 설계 점진적인 리팩터링과 구현의 반복에서 창발하는 설계 코드안에서 설계(명사) 발견 효율적인 추상화 모색 관용적 패턴을 수확 코딩이 여전히 단순 생산 작업인가?
  32. 32. 소스 코드 = 설계 문서
  33. 33. 코딩 = 설계
  34. 34. 두 공장 비교 구분 기존 모델 새 모델 설계 단계 포괄적 사전 설계 코딩 단계 생산 단계 코딩 단계 컴파일/빌드 단계 프로그래머 코더(단순 노동자) 설계자(전문가)
  35. 35. TDD 필수? 핵심은 점진적인 구현과 리팩터링의 반복 설계로서의 리팩터링 TLD + CI도 가능
  36. 36. 창발적 설계와 아키텍처
  37. 37. SW 아키텍처 “Architecture represents the significant design decisions that shape a system, where significance is measured by cost of change.”  ‑ Grady Booch
  38. 38. 오염된 도메인 추상 계층별로 관심사에 따라 계층을 나누고 다중 계층 아키 텍처 적용했으나 의존 방향이 잘못되어 도메인이 표현이나 데이터(Infra)에 역으로 의존하게 되는 상황
  39. 39. 전통적 계층형 아키텍처의 문제 추상 수준에 따라 계층을 나누는 계층형 아키텍처는 전통적 인 시스템 추상화 순서에 따라 계층을 나누기 때문에 도메인 계층이 데이터 계층에 의존하게 됨
  40. 40. DIP에 따른 계층형 아키텍처 “고차원의 모듈은 저차원의 모듈에 의존하면 안된다. 이 두 모듈 모두 다른 추상화된 것에 의존 해야 한다.”
  41. 41. 계층형 아키텍처 = 안티패턴
  42. 42. 진화하는 아키텍처 (evolutionary architecture) 설계가 코딩의 결과라면 결국 설계는 계획되는 것이 아니라 창발되는 것이며 아키텍처도 그에 따라서 진화해야 한다고 보는 관점
  43. 43. 스프링과 진화적 아키텍처
  44. 44. 결론 변화는 불가피하다, 기회로 활용하자 반복적인 리팩토링이 수반되는 코딩은 설계이다 코드 = 설계도, 코딩 = 설계 설계는 창발적 작업이다 창발적 설계를 지원하는 아키텍처는 진화할 수 있다 스프링은 창발적 설계와 진화적 아키텍처를 지원한다.

×