달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31

Use Case는 Delivering 매커니즘과 분리되어야 한다.

https://youtu.be/sYPsm93qIkY?t=9m23s



UI DB Framework Tool에 대한 결정은 Use Case와는 완전히 Decoupled 되어야 한다.

(Decoupled = 상관 없다 = 절연되어야 한다)



Use Case와 구현사항(UI FW WAS 등)이 분리되면 좋은 이유

1. 클라이언트에게 설명이 쉽다

2. 좋은 UI, FW, WAS 등의 결정을 미룰 수 있다(= 충분한 시간을 갖고 생각할 수 있다)



시장에서 통하는지 만들어 보는건 시간이 생명(변수명 아무렇게나, 카피&페이스트 권장)

여기까지는 굉장히 좋은데, 문제는 이 조잡한 시제품에 개발을 이어간다는 것.

새로 만들어야 하는데 그렇게 하지 않아서 문제 발생할 때 있음(리팩토링이라도 해야 하지만, 리팩토링보단 새로만드는게 훨씬 좋음)




https://www.youtube.com/watch?v=sYPsm93qIkY

'Design Pattern&UML' 카테고리의 다른 글

Concrete Class(구상 클래스)  (0) 2016.12.17
UML 기호 정리  (1) 2016.12.17
클린코더 영상 보고 공부중 - 디자인  (0) 2016.12.17
디자인 패턴의 5대 원칙 - SOLID  (0) 2016.12.11
[UML] 기호 정리 (초안)  (0) 2016.12.04
:
Posted by 클레잇