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