시간 있으면 설계나 합시다

1,443 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,443
On SlideShare
0
From Embeds
0
Number of Embeds
238
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

시간 있으면 설계나 합시다

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

×