Your SlideShare is downloading. ×
시간 있으면 설계나 합시다
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

시간 있으면 설계나 합시다

1,072
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,072
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 시간 있으면 설계나 합시다 아꿈사 (http://cafe.naver.com/architect1.cafe) Codevania (http://codevania.textcube.com)
  • 2. 설계를 회피하는 주된 변명
    • 설계는 저절로 드러납니다
    • 시간이 없습니다
  • 3.
    • 오류 처리라는 비극
    • 사공이 많으면 배가 산으로 간다
    • 적당한 설계란 ?
    • 품질의 이면 , 설계자와 아키텍트
    • 고립은 아름다워 , 더 나은 설계
  • 4. 오류처리
    • 꾸준하고 한결같이 지지 부진한 기능
    • 그렇다면… 코드가 스스로 오류를 해결하지 못하는 이유 ?
      • 오류가 발생한 사실과 이유 를 코드가 전혀 모름
      • 오류를 감지하더라도 처리할 오류 코드가 없음
  • 5. 문제 발생의 전형적인 상황
    • RECH
      • Routine for Error Central Handling
      • 모든 오류를 한 곳에서 처리하겠다는 의미
    • 예외 나 오류 값 둘 다 를 처리할 수는 없다
      • 예외만 처리한다면…예외를 씌우자
      • 오류값만 처리한다면… 오류 처리를 하자
      • 성공 / 실패 유무만 반환한다면… 둘 다 하자
      • 오류값을 의미 있게 반환한데도 , 위와 같은 함수에서 호출된다면… ?????????
  • 6. 정책
    • 오류 정보를 최대한 활용하자
      • 예외 를 사용하겠다
        • 코드 전체에서 예외를 사용하자
        • 프로그램 요소는 모두 객체로 정의 하자
      • 오류 값 을 사용하겠다
        • 의미 있는 오류 값을 넘기자
        • 오류가 발생한 곳에서 즉시 처리하자
      • 섞어 써야겠다
        • 정보를 잃지 않기 위해서…
        • 오류 값을 반환하는 코드는 예외 처리 루틴으로 감싸자
        • 예외를 던지는 코드는 오류값 반환 루틴으로 감싸자
  • 7. 오류 처리 위치
    • 오류 처리 함수가 수천 개까지 늘어나지 않도록
      • 해결 가능한 최상위 단계 에 오류 처리 코드를 추가
    • 사용자 에게 오류 를 보고 한다
      • 항상 돌아가는 시스템
      • 적어도 고객을 배려하는 시스템
      • … 으로 보이기 위해서
  • 8.
    • 오류 처리라는 비극
    • 사공이 많으면 배가 산으로 간다
    • 적당한 설계란 ?
    • 품질의 이면 , 설계자와 아키텍트
    • 고립은 아름다워 , 더 나은 설계
  • 9. 시갈의 법칙
    • 손목 시계가 한 개인 사람은 몇 시인지 정확히 알지만 , 손목 시계가 두 개인 사람은 절대로 현재 시각을 확신하지 못한다
  • 10. 일관성 통일성 Ctrl+c  Ctrl + v Drag  Drop
  • 11. 몇 시인지 아는 사람 ?
  • 12. 사공은 한 명으로 족하다네
    • ‘ 사공 하나 ’ 규칙
      • 모든 자료는 값을 다루는 사공이 하나면 족하다
      • 모든 연산은 연산을 수행하는 사공이 하나면 족하다
    • 그리기 , 자료 입력 , 메시지 처리 등 각 동작을 책임지는 사공이 하나 뿐이면  사용자 인터페이스가 일관성 을 유지한다
  • 13.
    • 오류 처리라는 비극
    • 사공이 많으면 배가 산으로 간다
    • 적당한 설계란 ?
    • 품질의 이면 , 설계자와 아키텍트
    • 고립은 아름다워 , 더 나은 설계
  • 14. 아무리 우수한 설계라도 제시간에 구현하지 못하면 무용지물 이다
  • 15. 어느 정도가 적당할까 ?
    • 설계를 건너 뛴다고 문제가 해결되진 않음
    • 제품 결함 중 40%~50% 는 설계 단계서 발생
    • 불명확한 설계 절차 하에 진행되는 프로젝트는 개발자 사기를 짓밟는 지름길
  • 16. 설계 완성도
    • 완성도
      • 설계 과정에서 가장 중요한 측면
      • 어느 정도가 적당할지 가늠하는 척도
    외부 내부 정적 PM 명세 개발 명세 API 정의 테스트 주도 개발 동적 유스 케이스 순서 다이어그램 시나리오와 퍼소나 상태 다이어그램 흐름도 위험과 실패 모델링
  • 17. 격차를 조심하라
    • PM 명세와 개발 명세 사이의 격차를 메우려면
      • ( 제품 기능과 같은 ) 기능적 요구 사항 을
      • ( 클래스나 컴포넌트와 같은 ) 설계 매개 변수 로
      • 변환하는 작업이 필요
    • 두 가지 방법
      • 설계 패턴
      • 공리적 설계
  • 18. 설계 행렬
    • 행 : 기능적 요구 사항
    • 열 : 설계 매개 변수
    • 기능 요구 사항이 서로 겹치지 않도록 주의
    • 복잡한 요구 사항  작은 요구 사항 여러 개
    • 새 요구 사항 추가  새 행을 추가
    • 기능 요구 사항 과 설계 매개 변수 가 만나는 칸 체크
    온수 꼭지 냉수 꼭지 레버 기울기 레버 회전 유량 X X 유량 X 수온 X X 수온 X
  • 19. 성공하는 방법
    • 이렇듯 체계적인 절차 를 따르자
      • 빠뜨릴 우려도 없다
      • 일정을 잡기도 쉽다
      • 정답 없는 인생의 압력에 시달리지 않아도 된다
    • 고객이 요구하는 품질 수준 에 맞춰야 한다
      • 버그 수를 천분의 몇 단위로 줄여야 한다
        • 요구사항을 선별하고
        • 요구사항에 충족하는 설계를 내놓아야 한다
    • 엔지니어링에 기반한 구현 기법과 빈틈 없는 설계 절차를 활용하자
  • 20.
    • 오류 처리라는 비극
    • 사공이 많으면 배가 산으로 간다
    • 적당한 설계란 ?
    • 품질의 이면 , 설계자와 아키텍트
    • 고립은 아름다워 , 더 나은 설계
  • 21. 품질 과 가치 는 인식 문제 고객과 비평가가 싫어하면 허섭스레기에 불과하다
  • 22. 전보다는 나아져야 한다
    • 시장 변덕에 대처하는 두 가지 방법
      • 새로운 기능으로 고객을 감동시킨다
      • 경쟁업체를 따라 잡는다
    • 불행히도…
      • “ 있는 기능이나 제대로 돌아가게 하세요”
      • 고객이 원하는 바를 정확히 알아야 따라잡는다
  • 23. 변화가 필요하다
    • 이런 악순환을 끊기 위해서 필요한…
    • 설계자 designer
      • 사용자 경험 , 즉 ‘무엇 what’ 을 정의하는 사람
    • 아키텍트 architect
      • 전체적인 구현 방법 , 즉 ‘어떻게 how’ 를 정의하는 사람
  • 24. 훌륭한 설계자
    • 고객 경험을 진심으로 이해
    • 전체적으로 빈틈없이 생각한 후 기술적인 한계를 초월하는 설계안을 제시
    • 고객을 감동 시킬 방법에 초점
    • 단순성 , 완전성 , 핵심 시나리오 , 고객 제약사항 , 현재 제품과 차별성 , 고객의 인식 가치를 최우선으로 고려
    • 꿈을 그려낸다
  • 25. 훌륭한 아키텍트
    • 모든 구현안에 대한 가능성 을 열어 둔다
    • 현실화하는 과정에서 비용 , 성능 , 보안 , 신뢰성 , 법적 고려사항 , 협력 관계 , 의존성 등 제약사항에 의해 현실적인 구현안이 도출되면서 , 최적의 고차원 구현 설계 가 드러난다
    • 필요한 제품과 컴포넌트의 아키텍처를 명료하게 묘사 ( 인터페이스 , 의존성 그래프 )
    • 꿈을 꾸되 두 발은 현실에서 떨어지지 않는다
  • 26. 훌륭한 설계자와 아키텍트
    • 제품 개발팀이 거짓말을 못하도록 감시 하고 충돌을 해결
      • 제품 개발팀과 협력 해 문제를 해결
    • 의사소통 기술 이 뛰어나야 한다
      • 제품 개발팀은 물론 서로 간에도 협력해서 일관적인 목소리와 지침을 제공
    • 세부 사항 검토할 때 큰 그림 을 잊어먹지 않는다
    • 프로젝트를 처음부터 끝까지 폭넓게 고려한다
      • 기능 / 제품 / 시장 경계까지 넘나들며 기회를 포착
  • 27. 벽을 넘어서
    • 설계자
      • 인공적인 경계를 초월해 가치 를 끌어내야 한다
    • 아키텍트
      • 경계를 무너뜨려 가치 를 현실화 해야한다
    • 행동하기 전에 폭넓게 생각 하고 , 끝까지 밀고 나가는 의지
    • 가장 힘겨운 경쟁 상대인 우리 자신을 이기자
  • 28.
    • 오류 처리라는 비극
    • 사공이 많으면 배가 산으로 간다
    • 적당한 설계란 ?
    • 품질의 이면 , 설계자와 아키텍트
    • 고립은 아름다워 , 더 나은 설계
  • 29. 쪼개기는 어려워
    • 아키텍처
      • 큰 제품 과 작은 팀 을 연결하는 방법
    • 아키텍처를 고민하는 이유
      • 까다로운 문제를 쉬운 문제 여러 개로 쪼개기 위해서
      • 제대로 하면 멋진 독립성 제공
  • 30. 잘 쪼개기
    • 탄탄 하고 , 안정적 이고 , 유연 한 아키텍처를 만드는 과정
      • 제품 아키텍처가 반드시 충족할 시나리오와 요구사항을 수집
      • 수집한 시나리오와 요구사항이 명확하고 완전하고 독립적인지 확인
      • 시나리오와 요구사항을 구현할 컴포넌트와 연결
      • 제품 컴포넌트 사이에 인터페이스를 결정
      • 컴포넌트와 인터페이스를 문서화
      • 문제점이나 새로운 요구사항이 떠오르면 재설계 및 리팩토링
  • 31. 팀에서 ‘나’는 없다
    • ‘ 팀으로서’ 모든 단계를 수행
      • 아키텍트는 대다수 이해관계자를 팀으로 소환
      • 그래야
        • 시간이 많이 단축
        • 아키텍처 일관성도 상승
    • 아키텍트로 아키텍처팀을 구성
      • 아주 복잡한 제품간 시나리오와 요구사항을 다루기가 쉬워짐
  • 32. 사이 좋은 견원지간
    • After 아키텍처를 문서화 , 컴포넌트 분리
      • 각 기능팀은 충돌없이 자유롭게 업무
      • 컴포넌트간 예외 사항 발생시 기민하게 대처
    • 아직 상향식 설계 작업 잔재
      • 개발 범위의 축소 / 코드 영향권이 한정되면서 테스트 주도 개발 등 애자일 기법 적용할 여지 충분
    • 하향식 : 독립성을 제공할 정도로만
    • 상향식 : 협력과 품질을 최적화  양쪽 세상에서 장점만 취하라