나는 겨우 충분한 소프트웨어 구조에서 배운 것이다.

최근에 나는 조지 필반크스의 소프트웨어 구조에 딱 알맞다는 책을 읽기 시작했다.이 책은 내가 임무의 경중과 완급을 확정하는 데 도움을 주었다.나는 이 책에서 배운 것을 여기에 첨가할 것이다.이것은 블로그 시리즈의 첫 번째 부분이다.
소프트웨어 구조는 소프트웨어를 구분하고 지식을 제공하며 추상적으로 문제의 본질을 밝히는 데 도움이 된다.
리스크 구동 구조는 프로젝트의 리스크를 우선적으로 고려한다.그래서 우리는 하나의 특성만 고려하는 것이 아니라 위험을 무릅쓰고 고려한다.우리는 모든 팀에 대해 같은 절차를 따를 수 없다. 왜냐하면 모든 팀은 서로 다른 유형의 위험을 가지고 있기 때문이다.
위험의 정의는 실패의 가능성에 실패의 영향을 곱하는 것이다.그러나 실패와 영향을 가늠하는 정확한 확률은 쉽지 않다.따라서 우리는 리스크의 가능성과 영향에 대한 가설을 이용하여 리스크를 평가한다.
설령 우리가 위험이 없다고 완전히 확정한다 하더라도, 우리가 그것을 분석하고 테스트할 때까지 보장할 수는 없다.분석과 테스트를 위해서 우리는 존재할 수 있는 위험을 이해해야 한다.

            **Risks**

리스크 묘사: 리스크 유형과 리스크 유형을 이해하는 것은 매우 중요하다. 왜냐하면 모든 리스크는 서로 다른 처리 방식이 있기 때문이다.프로젝트 관리 리스크와 공사 리스크처럼 우리는 이 두 가지 리스크를 같은 방식으로 처리할 수 없다.
서버가 1M 사용자를 처리할 수 없는 것은 프로젝트 리스크이고, 리더 팀 구성원에게 사고가 발생하는 것은 프로젝트 리스크로 둘 다 다른 방식으로 처리해야 한다.
위험 식별: 수요 수집은 우리가 위험을 식별하는 데 도움을 줄 수 있다.만약 당신이 새로운 분야에서 일한다면, 수요를 수집하고, 실현하기 어려울 것 같은 일을 열거하세요.
전형적인 리스크: 어떤 분야에 약간의 리스크가 존재한다.이 리스크 리스트는 경험이 적고 경험이 풍부한 개발자들에게 매우 가치가 있다.
위험을 우선적으로 고려: 모든 위험이 동등한 영향을 미치는 것은 아니다.그래서 우리는 위험을 우선적으로 고려해야 한다.그러나 팀에 따라 우선순위가 다를 수 있다.지도자의 말에 따르면 개발진에게 매우 중요한 위험은 그다지 중요하지 않을 수도 있다.따라서 만약에 당신이 어떤 위험에 충분한 시간을 들였다면 지도자와 토론하고 우선순위도 알아야 한다(어떤 위험은 개발팀만 결정할 수 있다).
나는 3월 26일에 다음 블로그를 쓸 것이다